On 09/29/2009 04:16 PM, Paul Brook wrote: >> char f[4]; >> ... >> any idea why gcc would lay out the memory differently for armel than for >> i386? i haven't tried it on the old arm architecture. > > The alignment of "f" is entirely arbitrary. > > It could be effected by any number of things, including but not limited to > where other variables happen to be placed, ABI differences, how aggressively > the compiler chooses speed over size, exact compiler versions and, if you're > really unlucky, phase of the moon. true, i'm not saying it's non-compliant that it's char-aligned. it's just interesting to observe that in i386, it seems to be guaranteed to be word-aligned, even if i do: char g; char f[4]; both &g and f are 32-bit aligned on i386. not so when i build on armel. given armel's failures on alignment errors (and i386's apparent ability to handle them gracefully -- try passing f+1 to test() ) i find it curious that gcc would be *more* cautious about over-alignment on i386 than on armel. --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature