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.