https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #55 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- (In reply to H.J. Lu from comment #54) > (In reply to alalaw01 from comment #53) > > > > > >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid? > > > > Not everyone wants to patch SPEC sources. > > If the SPEC source is invalid according to Fortran standard, why should > we change GCC for it? This isn't the only invalid source in SPEC CPU > 2006. There are at least 3. The Fortran code is obviously legacy code. I think handling it behind -std=legacy is the correct flag. ----snip---- > > > > --- Comment #45 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > > Consider e.g. one source file > > INTEGER FOO > > COMMON /BLK/ K(64) > > DO I=1,64 > > K(I)=1 !!!!!!! typo should be =I > > END DO > > IF (FOO(5,12).NE.51) CALL ABORT > > END > > and another one: > > FUNCTION FOO(I, J) > > COMMON /BLK/ K(1) > > FOO = K(I) + K(J) + K(2*I) + K(2*J) > > END FUNCTION Note: Typo in the example The correct solution to me is to detect the unequal sizes and convert the COMMON /BLK/ K(1) to the larger size, ie K(64). Currently we accept this code when it is all in one file and give a warning only. Playing with the test case in two files I see the problem is only with K(1), K(2) or anything else gives correct results when optimized -O2, O3 etc. Based on what I am seeing, I see no need for a flag at all, just a warning and create the block to the size of the largest specified.
