RFA: Darwin x86 alignment

[Dale Johannesen]

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.