[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
jvdelisle at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Feb 18 21:15:00 GMT 2016
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.
More information about the Gcc-bugs
mailing list