Chris Lattner <sabre@xxxxxxxxxx> writes:
> On Tue, 25 Jul 2005, Ian Lance Taylor wrote:
> >> ... the struct maintains its 8-byte alignment even though nothing
> >> inside of it requires 8-byte alignment any more.
> >
> > When I try that with a powerpc-eabi compiler, it appears to generates
> > a struct with a size of 12 bytes and an alignment of 4 bytes. Do you
> > not see that with a Darwin compiler? What target are you configuring
> > for? What sources are you using?
>
> This is a powerpc-darwin specific issue I believe. The Darwin ABI
> states (roughly) that doubles have 4-byte alignment, unless they are
> the first element of a structure (in which they have 8-byte
> alignment). I think this is a holdover from AIX compatibility.
>
> It is my guess that this ABI rule is overruling the user request, but
> I don't really know how to go about verifying this, or working around
> it :(
OK. From the source code, that seems to be happening in
rs6000_special_round_type_align (config/rs6000/rs6000.c), which is
called by ROUND_TYPE_ALIGN (config/rs6000/darwin.h), which is called
by finalize_record_size (stor-layout.c).
rs6000_special_round_type_align is given the computed alignment and
the user specified alignment. It appears to always force a maximum of
64.
Tracking this back through time and across files, it appears to have
been introduced here:
Mon Apr 22 12:00:46 1996 David Edelsohn <edelsohn@xxxxxxxxx>
* rs6000.h (BIGGEST_FIELD_ALIGNMENT): Delete.
(ADJUST_FIELD_ALIGN, ROUND_TYPE_ALIGN): Define.
when it looked like this:
/* AIX increases natural record alignment to doubleword if the first
field is an FP double while the FP fields remain word aligned. */
#define ROUND_TYPE_ALIGN(STRUCT, COMPUTED, SPECIFIED) \
((TREE_CODE (STRUCT) == RECORD_TYPE \
|| TREE_CODE (STRUCT) == UNION_TYPE \
|| TREE_CODE (STRUCT) == QUAL_UNION_TYPE) \
&& DECL_MODE (TYPE_FIELDS (STRUCT)) == DFmode \
? MAX (MAX ((COMPUTED), (SPECIFIED)), BIGGEST_ALIGNMENT) \
: MAX ((COMPUTED), (SPECIFIED)))
The code now looks like this for a struct which begins with a double:
return MAX (MAX (computed, specified), 64);
This ignores the attribute ((packed)), and I don't see why it is
correct to do so.
Ian
