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.
