[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues

["tobi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #20 from Tobias Schlüter <tobi at gcc dot gnu.org> ---
Let's please not invent new semantics.  There are two things to distinguish:
1) legacy code, where no interoperability semantics were defined
2) new code, where the semantics are defined

I don't know much about 2), but I do know that the recommendation back in the
days was that a common block is represented by a struct, and everybody knew
that the layout of a struct with a single variable is the same as for the
variable itself.  I don't think anybody was silly enough to nest structs around
their variable.

Unfortunately, this is still not entirely simple.  Fortran allows accessing the
same memory by different names which may have different types: what do you do
with
 INTEGER A, B, C
 COMMON /D/ E(3)
 REAL E
 EQUIVALENCE (E(1),A), (E(2),B), (E(3),C)
?

Or, to make things even more annoying
 DOUBLE PRECISON X
 INTEGER I(2)
 EQUIVALENCE (X, I(1))
 COMMON /annoying/ X
?

There's one more problem: Fortran's TYPE, the equivalent of the struct {}, was
defined in Fortran 90 -- before the interoperability stuff.  So the question is
what to do with common block that contain a single TYPE variable.

Until I started writing this, I tought "well, just allow this struct vs. single
variable only for single-valued, scalar contents of the common block", but my
second example showed me that this wouldn't work -- after all is the common
content scalar (one double) or array-valued (two ints)?

Now, since we're talking about legacy stuff and we don't want to invent new
language rules, I think we can restrict ourselves to supporting the simplest
case: a single INTEGER, REAL or DOUBLE PRECISION ignoring possible
EQUIVALENCES, but I don't know if this is easily achieved on the LTO side. 
Going further is not worth it, it's not like there are heaps of bug reports
about this problem.
>From gcc-bugs-return-456297-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 14 13:07:16 2014
Return-Path: <gcc-bugs-return-456297-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11609 invoked by alias); 14 Jul 2014 13:07:15 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11486 invoked by uid 48); 14 Jul 2014 13:07:09 -0000
From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues
Date: Mon, 14 Jul 2014 13:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.5.0
X-Bugzilla-Keywords: lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fxcoudert at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-41227-4-tVzQ31PPzQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-41227-4@http.gcc.gnu.org/bugzilla/>
References: <bug-41227-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg00888.txt.bz2
Content-length: 1245

https://gcc.gnu.org/bugzilla/show_bug.cgi?idA227

--- Comment #21 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #18)
> By your argument,
>   int i;
> and
>   struct { int i; } a;
> are interoperable.

No. The standard only defines interoperability as a one-to-one mapping between
one Fortran entity and one C entity.

An "extern int i" and "integer(int_c) :: i" are interoperable. By the standard,
a common block with i as single variable is interoperable with "extern struct {
int i; } a;" or "int i;" (where the question is whether "or" is exclusive or
not).

But I don't see how you can expand that to mean that the common block is
interoperable with "struct { struct { int i; } a; } a;" by a simple reading of
the standard. There are, in my reading, 2 or 3 (with the same "or" as before)
entities interoperable with this nested struct:

  - a derived type containing a derived type containing "integer(int_c) :: i"
  - a common containing the dt containing the dt
  - a common containing a derived type containing "integer(int_c) :: i"


> Otherwise, I stand to what I wrote before: I think the standard does not
> demand the interoperability.

Let's raise a formal interp, then.