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.
