On some systems, such as those with Pentium Pro CPUs, programs
that make heavy use of REAL(KIND=2) (DOUBLE PRECISION)
might run much slower
than possible due to the compiler not aligning these 64-bit
values to 64-bit boundaries in memory.
(The effect also is present, though
to a lesser extent, on the 586 (Pentium) architecture.)
The Intel x86 architecture generally ensures that these programs will work on all its implementations, but particular implementations (such as Pentium Pro) perform better with more strict alignment. (Such behavior isn't unique to the Intel x86 architecture.) Other architectures might demand 64-bit alignment of 64-bit data.
There are a variety of approaches to use to address this problem:
COMMON and EQUIVALENCE areas such
that the variables and arrays with the widest alignment
guidelines come first.
For example, on most systems, this would mean placing
COMPLEX(KIND=2), REAL(KIND=2), and
INTEGER(KIND=2) entities first, followed by REAL(KIND=1),
INTEGER(KIND=1), and LOGICAL(KIND=1) entities, then
INTEGER(KIND=6) entities, and finally CHARACTER
and INTEGER(KIND=3) entities.
The reason to use such placement is it makes it more likely
that your data will be aligned properly, without requiring
you to do detailed analysis of each aggregate (COMMON
and EQUIVALENCE) area.
Specifically, on systems where the above guidelines are
appropriate, placing CHARACTER entities before
REAL(KIND=2) entities can work just as well,
but only if the number of bytes occupied by the CHARACTER
entities is divisible by the recommended alignment for
REAL(KIND=2).
By ordering the placement of entities in aggregate
areas according to the simple guidelines above, you
avoid having to carefully count the number of bytes
occupied by each entity to determine whether the
actual alignment of each subsequent entity meets the
alignment guidelines for the type of that entity.
If you don't ensure correct alignment of COMMON elements, the
compiler may be forced by some systems to violate the Fortran semantics by
adding padding to get DOUBLE PRECISION data properly aligned.
If the unfortunate practice is employed of overlaying different types of
data in the COMMON block, the different variants
of this block may become misaligned with respect to each other.
Even if your platform doesn't require strict alignment,
COMMON should be laid out as above for portability.
(Unfortunately the FORTRAN 77 standard didn't anticipate this
possible requirement, which is compiler-independent on a given platform.)
gcc configuration subsystem).
The warning about this in the gcc manual isn't
generally relevant to Fortran,
but using it will force COMMON to be padded if necessary to align
DOUBLE PRECISION data.
When DOUBLE PRECISION data is forcibly aligned
in COMMON by g77 due to specifying `-malign-double',
g77 issues a warning about the need to
insert padding.
In this case, each and every program unit that uses
the same COMMON area
must specify the same layout of variables and their types
for that area
and be compiled with `-malign-double' as well.
g77 will issue warnings in each case,
but as long as every program unit using that area
is compiled with the same warnings,
the resulting object files should work when linked together
unless the program makes additional assumptions about
COMMON area layouts that are outside the scope
of the FORTRAN 77 standard,
or uses EQUIVALENCE or different layouts
in ways that assume no padding is ever inserted by the compiler.
Note: `-malign-double' applies only to
statically-allocated data.
Double-precision data on the stack can still
cause problems due to misalignment.
See section Aligned Data.
main().
The recent one from GNU (glibc2) will do this on x86 systems,
but we don't know of any other x86 setups where it will be right.
Read your system's documentation to determine if
it is appropriate to upgrade to a more recent version
to obtain the optimal alignment.
Progress is being made on making this work
"out of the box" on future versions of g77,
gcc, and some of the relevant operating systems
(such as GNU/Linux).
Go to the first, previous, next, last section, table of contents.