Node: Aligned Data, Next: Prefer Automatic Uninitialized Variables, Up: Faster Programs
On some systems, such as those with Pentium Pro CPUs, programs
that make heavy use of
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:
EQUIVALENCEareas such that the variables and arrays with the widest alignment guidelines come first.
For example, on most systems, this would mean placing
INTEGER(KIND=2) entities first, followed by
LOGICAL(KIND=1) entities, then
INTEGER(KIND=6) entities, and finally
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 (
Specifically, on systems where the above guidelines are
CHARACTER entities before
REAL(KIND=2) entities can work just as well,
but only if the number of bytes occupied by the
entities is divisible by the recommended alignment for
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.)
-malign-doubleoption when compiling programs for the Pentium and Pentium Pro architectures (called 586 and 686 in the
gccconfiguration subsystem). The warning about this in the
gccmanual isn't generally relevant to Fortran, but using it will force
COMMONto be padded if necessary to align
DOUBLE PRECISION data is forcibly aligned
g77 due to specifying
g77 issues a warning about the need to
In this case, each and every program unit that uses
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,
EQUIVALENCE or different layouts
in ways that assume no padding is ever inserted by the compiler.
crt1.oon your system guarantees a 64-bit aligned stack for
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
gcc, and some of the relevant operating systems
(such as GNU/Linux).