> Just because the default build won't make use of this doesn't mean that 
> the ABI shouldn't allow for it.  We want to allow applications that are 
> compiled for a restricted set of CPU targets to get most advantage out of 
> the system  (... if I know my application will only ever run on an XScale, 
> why shouldn't I take advantage of that fact?)

Yes - I maybe I was winding you up :-)
 
> > Mind you I would have expected the ABI to specify that double be
> > aligned on 8 byte boundary, and 'complex double' and 'long double'
> > on 16 byte (I've forgotten the exact names for these types).
> > Not doing so is asking for trouble down the line....
> 
> Doing so would break the procedure calling convention in a major way.  
> Since doubles would be aligned in memory, the va-args issue would 
> effectively force doubles into even-numbered pairs of integer regs.  That 
> has nasty consequences which aren't really worth the gain.

I don't see how knowing that malloc() returns an 8 byte (or greater)
aligned pointer helps the compiler unless it knows that (almost)
all 8 byte items are aligned.

The procedure calling convention is problematical, especially for
var-args functions and printf() - is the format string required to
use all the arguments?

If the stack is aligned, then the compiler knows the alignment of fp
parameters.  If they are misaligned and their address is taken then
then presumably an aligned copy must be made.
Can you take the address of a varags parameter?

> 
> > Maybe gcc should issue a warning whenever it misaligns items within
> > a structure?  Can it remember which items ought to be aligined?
> 
> I don't think that would be sensible either.

What does --strict-align do?

	David