[Bug fortran/37486] alignment of data in COMMON blocks

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

------- Comment #7 from kargl at gcc dot gnu dot org  2008-09-12 21:18 -------
(In reply to comment #6)
> > This is equivalent to the ever popular use of EQUIVALENCE to set a
> > real type to Inf or NaN via integers.
> 
> Actually, it is a bit different: Here, already the COMMON is invalid for
> EQUIVALENCE only accessing the value is invalid as the value is undefined.

I can't parse the above sentence. :(

> Default integer and default real are in the same storage sequence (and here
> probably the analog to EQUIVALENCE holds). I think the following program is
> valid according to the standard and it has the same problem:
> 
> subroutine one()
>   integer :: i
>   common /com/ i
>   print *, i
> end subroutine one
> 
> program test
> integer :: j
> real(8) :: r8
> common /com/ i, r8 
> i = 5
> call one()
> end program test
> 
> (If I recall correctly, the commons do not need to have the same size, but the
> shorter ones need to be identical to the longer one minus the extra elements.)

Yes, the above is a valid program via 5.5.2.1(2) of the F95 standard.

A problem does not exist if by default gfortran does not pad the
common block to align double precision types on 8 byte boundaries.

Returning to your code in comment #1.  The two common statements
occupy 5 storage units.  As soon as gfortran puts padding into
the "common /foo/ n1,r1,n2,n3", gfortran has violated 5.5.2.1(1) of
the standard because it is changing the storage sequence of 
"common /foo/n1,n2(2),n3,n4".

To summarize, gfortran should not pad common blocks.  gfortran can
issue a warning alerting the user of an align issue if one exists.
gfortran should implement a -falign-common option to user a gun to
blow their feet off.


-- 


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