[Bug fortran/44882] [4.6 Regression] Bogus types in references with mismatched commons

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

------- 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