On Jul 23, 2005, at 6:40 AM, Tobias Schlüter wrote:
I have a strong suspicion there is a reason why the two are linked,
and that that reason is FORTRAN. A lot of FORTRAN code assumes
EQUIVALENCE of floating-point and integer types of equal size. Such
code will in all likelyhood break if those types have different
alignment. For x86 this means that int/float and long long/double
will have to have the same alignment.
This might indeed be a problem, as the alignments not only have to be
the same
if they appear in an equivalence, but also in arrays or when using the
TRANSFER intrinsic. Out of the types dicussed, the standard only
specifies
this for default INTEGERs (=int in C) and default REALs (=float in C),
but
users do expect this to consistently extend to bigger types, otherwise
they
consider the compiler buggy instead of their code.
Thanks for bringing this up. It's probably true that nobody has
thought about Fortran,
but so far I'm not convinced it would actually be a problem. Can
somebody provide
an example that would break?
More precisely, the standard says this: a scalar variable of a certain
type
occupies a certain number of "storage units". Default INTEGERs, and
REALs
take one storage unit, default COMPLEX and DOUBlE PRECISION (= REAL*8
= double
in C) take two storage units. Finally, arrays of these types take a
sequence
of contiguous storage units.
I know. These rules aren't affected by target alignments, though, and
I would
not expect the Fortran FE to be affected by alignments when doing
layout. If it is, why?
The compiler already has to deal with misaligned data in Fortran:
INTEGER I(3)
DOUBLE PRECISION A,B
EQUIVALENCE (A,I(1)), (B,I(2))
not to mention the user-specified alignment extensions in C, so I
wouldn't expect
the optimizers to break or anything like that.
