[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53086

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |fortran

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-24 07:57:43 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > 
> > From F2003 standard one finds on page 99:
> > 
> >    The form variable-name (explicit-shape-spec-list) declares variable-name
> >    to have the DIMENSION attribute and specifies the array properties that
> >    apply.
> > 
> > My interpretation is that
> > 
> >       COMMON /FMCOM / X(1)
> > 
> > declares X to have 1 element while
> > 
> >       PARAMETER (MEMSIZ=   80 000 000)
> >       COMMON /FMCOM / X(MEMSIZ)
> > 
> > has 80000000 elements.  The above appears to be a common
> > F77 idiom for "dynamic" memory management where the 
> > programmer is abusing the storage association of element
> > x(1).
> 
> I was told that it was allowed in F77.

If it is allowed in F77 then the GFortran frontend needs to be fixed.  First,
-fbounds-check may not fail, second, the array type in the COMMON aggregate
type shall not have a defined size (instead it would come from the COMMONs
DECL_SIZE).

Thus, this is a frontend bug which is pre-existing with -fbounds-check
and in 4.8 triggers wrong-code generation.