This is the mail archive of the mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: COMMON requires 4 bytes of padding at start

Janus Weil wrote:
> I think this is much better.
That patch is OK for the the trunk with the following changes.

a) Can you add in

+@item -Walign-commons
+@opindex @code{Walign-commons}
+@cindex warnings, alignment of COMMON blocks
+@cindex alignment of COMMON blocks
+By default, @command{gfortran} warns about any occasion of variables being
+padded for proper alignment inside a COMMON block. This warning can be turned
+off via @option{-Wno-align-commons}.

a "See also -falign-commons." as the latter gives the background for this warning.

b) For the following

              if (gfc_option.warn_align_commons)
                if (strcmp (common->name, BLANK_COMMON_NAME))
                  gfc_warning ("Padding of %d bytes required before '%s' in "

I get a warning that one should use "{ }", which stops compiling due to
-Werror. Can you add the { } ?

c) Just to make sure (because of (b)): Did you build + run the test
suite with your modified patch? If not, you better do this before you

Can you after the check in also update the Wiki (gfortran -> news) and
create a patch for the changelog?

(If you don't want to work with CVS, I can also check in that patch; you
need to submit it anyways as "wwwdocs" patch.)

Thanks for the patch!

  * * *

Additionally I wonder whether one should not change the default padding
as follows (in a follow-up patch),

  integer*4 i
  real*8 r8
gfortran currently produces:
  <pad 4> + i + r8
I think it makes more sense to use
  i + <pad 4> + r8

Using that, the following commons work even with alignment:
  common i ! in one subroutine
  common i, r8 ! in another subroutine

(The standard allows that blank commons can have a different number of
elements at different places. If an element is present, it needs to be
conformable with the same element at all other commons. Legacy programs
of cause make use of  2×  integer*4  = integer*8 etc., which is not
standard conform and will fail due to the alignment issues.)

I think this is the only strictly standard conforming program which will
fail - or at least the most common one. A quick check shows that NAG
f95, Pathscale, Open64 and PGI do such a padding & due to the
no-alignment it also works in g95, sunf95 and ifort. It only fails in
g77 and gfortran.*


* I tested the padding with the following program, which is presumably
not standard conform, but when removing "j" it is standard conform and
should print "5" and not "0" as it does with gfortran. Result of the
program below:
- gfortran and g77 print "0 5"
- ifort, sunf95 and g95 print "5 1267487353"
- pathscale, pgi, and NAG f95 print "5 0".

subroutine one()
integer :: i
common i,j ! Without "j" is is standard conform
print *, i,j ! i should be 5.
end subroutine one
program test
integer :: j
real*8 r8
common i, r8
i = 5
r8 = 123457891234d88
call one()
end program test

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]