https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |vmakarov at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looking at 416.gamess, I see mess like:
$ cat /tmp/a.f90
common /a/ i(10)
i(:) = 1
call foo (10)
end
$ cat /tmp/b.f90
subroutine foo (j)
common /a/ i(1)
l = 0
do k = 1, j
l = l + i(k)
end do
print *, l
end subroutine foo
$ gfortran -o /tmp/a /tmp/a.f90 /tmp/b.f90 -O2 -Wall; /tmp/a; gfortran -o
/tmp/b /tmp/a.f90 /tmp/b.f90 -O2 -Wall -fno-aggressive-loop-optimizations;
/tmp/b; gfortran -o /tmp/c /tmp/a.f90 /tmp/b.f90; /tmp/c
1
10
10
Is that valid Fortran at all? To the middle-end, the array (at the end of) the
COMMON block is represented as a structure containing a fixed bound array, so
the middle-end (rightfully) thinks that only X(1) is valid, but X(2) and higher
are undefined behavior. If Fortran as language allows this, either everywhere,
or for compatibility in some mode, it would be better if such common blocks
were modeled similarly to C99 flexible array members with GNU extension of
initializing that; which is that the type of last RECORD_TYPE's FIELD_DECL
should have NULL max bound, and only the VAR_DECL would have size reflecting
the actual array size. Of course, only the last array in the COMMON block
could be handled this way, if some (broken?) Fortran code still wants say
COMMON /XX/ X(1), B, C, D, Y(20)
and happily access X(2) as B, X(3) as C, X(4) as D, X(6) as Y(2) etc., then
I'm afraid -fno-aggressive-loop-optimizations is the only thing to do for such
code (and probably more than that).
>From the comments in unport.F, it looks like 416.gamess has commented out even
far uglier hacks, in particular using the COMMON /FPCOM / X(1) and then
when accessing it biasing index by some variable, which is initialized as a
difference between a heap region and the array in the common block. That would
be even worse for the middle-end and C semantics, dunno what Fortran as
language ever allowed and what needs to be (optionally?) tolerated to get badly
written code working.
