http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53086
--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-04-24 14:49:18 UTC --- On Tue, Apr 24, 2012 at 07:57:43AM +0000, rguenth at gcc dot gnu.org wrote: > 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. Fortran 2008 is backwards compatible with Fortran 2003. Fortran 2003 is backwards compatible with Fortran 95. Fortran 95 is backwards compatible with Fortran 90. Fortran 90 is backwards compatible with Fortran 77. There are some well-defined exceptions. None involve COMMON. F77 states: 8.3.2 Common Block Storage Sequence For each common block, a common block storage sequence is formed as follows: (1) A storage sequence is formed consisting of the storage sequences of all entities in the lists nlist for the common block. The order of the storage sequence is the same as the order of the appearance of the lists nlist in the program unit. (2) (Not relevant) 8.3.3 Size of a Common Block The size of a common block is the size of its common block storage sequence including any extensions of the sequence resulting from equivalence association. Within an executable program, all named common blocks that have the same name must be the same size. For the two lines COMMON /FMCOM / X(1) PARAMETER (MEMSIZ= 80 000 000) COMMON /FMCOM / X(MEMSIZ) the named common block FMCOM have different sizes. The code is invalid and abuses the notion that X(1) are storage associated. > 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. The bug is in the Fortran code. Given the following code fragments from two different subroutine in a program COMMON /FMCOM / X(1), A PARAMETER (MEMSIZ= 80 000 000) COMMON /FMCOM / X(MEMSIZ), B is A storage associated with B or X(2)?
