------- Comment #38 from mark at codesourcery dot com 2006-01-20 18:02 -------
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> ------- Comment #37 from matz at suse dot de 2006-01-20 16:36 -------
> Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
> to further fiddle with alignments of fields. On x86 this is used to
> adjust the alignment of long long to 4 (instead of the natural 8).
> This is used only when the field is not DECL_PACKED (makes sense).
> This has the funny side-effect that a struct containing a long long zero-width
> bitfield aligns to 4 for unpacked and to 8 for packed structs
Ugh. I think we can all agree that these issues had not been well
thought through previously. :-)
> if (! DECL_USER_ALIGN (decl) && ! DECL_PACKED (decl))
> {
> #ifdef ADJUST_FIELD_ALIGN
> DECL_ALIGN (decl) = ADJUST_FIELD_ALIGN (decl, DECL_ALIGN (decl));
> #endif
> }
>
> Now, I could just ignore DECL_PACKED for zero-width bitfields, then the
> adjustment would be done for both cases and we had a size of 12 with
> attribute or pragma, i.e. not the same as pre 3.4 in both.
I don't think a zero-width bitfield should ever be DECL_PACKED. (In
this case, it's DECL_PACKED because the structure is in the scope of
#pragma pack(1).)
In other words, I think a zero-width bitfield should always be subject
to ADJUST_FIELD_ALIGN; the meaning of a zero-width bitfield of type T
(for PCC_BITFIELD_TYPE_MATTERS) should be "align the next field as you
would a field of type T".
> I'm leaning towards not doing field adjustments for zero-width bitfields
> at all, having the effect that a zero-width bitfield has a user-alignment
> set explicitely (of it's base type).
Careful! That would be an ABI change even in the non-packed case, which
we don't want to do.
I think the best change would be just not to mark zero-width bitfields
as DECL_PACKED in the first place; a second choice, if easier, would be
to disregard the DECL_PACKED setting in stor-layout.c. Please add a
test case for this new oddity you discovered, if you would.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
