------- Comment #9 from rguenther at suse dot de 2010-07-09 12:21 -------
Subject: Re: [4.6 Regression] Bogus types in references
with mismatched commons
On Fri, 9 Jul 2010, burnus at gcc dot gnu dot org wrote:
> ------- Comment #8 from burnus at gcc dot gnu dot org 2010-07-09 12:16
> -------
> (In reply to comment #5)
> > I'm going to leave the bug open after that because I think the Fortran
> > frontend should do better than overriding the type of the common in TRUDGE
> > from the unused variant in TRUSRC.
>
> Can you be a bit more specific what the solution of the problem should be?
Good question. I'd say never change types like that, just leave the
original type in place. The code is not a valid fortran program anyway
and this avoids invalid trees in the middle-end.
So for the testcase make TRUPAR DR and V real=4, if you'd change it to
SUBROUTINE TRUSRC(LEAVE)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
COMMON /TRUPAR/ DX(10),V(10,10)
END
SUBROUTINE TRUDGE(KDIR)
COMMON /TRUPAR/ DR(10),V(10,10)
DO 110 I=1,NDIR
110 DR(I)=V(I,JDIR)
END
make it real=8.
> > Sooner or later you'll trip into another ICE with these mismatched types in
> > the IL. Why can't this be a hard error?
>
> "Named common blocks of the same name shall be of the same size in all scoping
> units of a program in which they appear, but blank common blocks may be of
> different sizes." (5.7.2.5, Fortran 2008 (FDIS).)
>
> Thus, for blank commons, the standard requires to support it - while for named
> commones (such as TRUPAR in comment 1), it does not allow it. However, that
> did
> not stop people from doing so - and the number of (legacy) code which does so
> is legion.
And when compilers do not reject such code it will never be fixed ;)
Does GFortran have something like -fpermissive?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882
