From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 3F0F3382B3EE; Sun, 11 Dec 2022 22:15:32 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F0F3382B3EE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1670796932;
	bh=LLVMxihJnpWpl3YB619O/hAgnUKVLhZ7EosZzGAxSB8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=uboZfsDiUVOaRmnA18mDXUUp54350JMeN7ek8Ida0xYmC+FojR/WEeiV0CCFKRIXe
	 A2uNewqQkvddZpj0IgZvSkMlg+cR3MjOHAx0UedkwZDK1ky6lftWxLWMiyiYdBHQye
	 +m5hQZ5VB2kFHnvRUTVUd7JFA2qsUp2iFVqO4wo4=
From: "sandra at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/108056] [12/13 Regression] backward compatibility
 issue between 11 and 12
Date: Sun, 11 Dec 2022 22:15:31 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: ABI
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sandra at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108056-4-xgnoCGnXpu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108056-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108056-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108056

--- Comment #7 from sandra at gcc dot gnu.org ---
I've swapped out just about all the details on this work after more than a
year, but....  we shouldn't be trying to create a CFI descriptor with
BT_ASSUMED at all, should we?  If the compiler is generating a CFI descript=
or
for an assumed-type argument it's supposed to use the actual type of the
argument passed, not BT_ASSUMED, right?  If gcc 11 had a bug that caused it=
 to
do that incorrectly, is it necessary to retain ABI compatibility by continu=
ing
to reproduce the bug in newer versions of libgfortran?  Maybe we should just
remove the functions that are allegedly there for compatibility so that use=
rs
will get a link error instead?=