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