Re: [head tinderbox] failure on arm/arm

On Sun, Nov 12, 2006 at 01:21:05PM -0500, Alexander Kabaev wrote:
> GCC expects 4-byte aligned structured on ARM but does not necessarily
> have to. We can change the default at the expense of possible more
> inefficient code generated and lost binary compatibility with other ARM
> OSes out there. So this is trade off between unclear performance
> penalty and an unspecified but certainly sizable number of other
> landmines like this lurking on the code.
> 
> We should decide what evil we regard as lesser.
> 
This is the only buildworld problem so far on FreeBSD/ARM, so my
feeling is that we can actually benefit from leaving it "as is",
as it has a potential of making our code more portable.  Of course
if binary compatibility for structs across platforms is an issue,
a structure should be "packed", because otherwise the C standard
says that "Each non-bit-field member of a structure or union object
is aligned in an implementation-defined manner appropriate to its
type."

On the other hand, having GCC align "struct foo { char x[11]; }"
on a four-byte boundary (other than for backward compatibility)
doesn't make too much sense to me.

I don't know GCC rules for alignment of structure members.  For
example, if it's guaranteed (in GCC) that offsetof(struct foo, bar)
is always 1 for "struct foo { char foo; char bar; }" (without the
"packed" attribute) on all platforms and OSes GCC supports?
I'd expect the latter to be "4" for FreeBSD/ARM but fortunately
it stays "1", i.e., only the structure alignment is affected,
and not of structure members (which is POLA but makes the 4 byte
for structure alignment questionable).


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer