[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)

[matz at suse dot de]

------- Comment #32 from matz at suse dot de  2006-01-19 14:44 -------
Mark, I agree that it's saner when both structures (with #pragma pack and
attribute packed) have the same length of 8 on i686 and x86_64 (because
the bitfield was declared 'int' in difference to 'long' for instance).

Then I have a question to clarify if I understood correctly: by remembering
the original maximum_field_alignment and using that for zero-sized bitfields
you want to use the absolute first, default, m_f_a, or the one last set
before the innermost #pragma pack?  Consider an example like so, and lets
assume the initial max field alignment was 4:

mfa == 4
#pragma pack(2)         // 1  mfa == 2
#pragma pack(1)         // 2  mfa == 1
#pragma pack()          // 3  mfa == 4
#pragma pack (push,2)   // 4  mfa == 2
#pragma pack (push,1)   // 5  mfa == 1
#pragma pop             // 6  mfa == 2
#pragma pop             // 7  mfa == 4

With what would you constrain the alignment of a zero sized bitfield
at each of the seven points?  What if the initial mfa is 0 (i.e. not set)?
Should -fpack-struct=... (which influences the initial mfa) influence
that constraint too, or not?

My opinion is, that at each of the seven points above we should constrain
with the initial mfa (i.e. 4 in the example above), as adjusted by
the -fpack-struct command line option.

That would have the effect of aligning zero sized bitfield at max to the
architecture default (possibly adjusted globally by the cmdline option),
while effectively ignoring all #pragma packs in effect.  I think that is
what we want the semantics of a zero-sized bitfield to be.  Agreed?

Another point: If we make the structure with attribute packed on both x86 and
x86-64 be eight long (to agree with the behaviour of using pragma), then we
do add another variant unfortunately.  In pre 3.4 that structure was 12 on
x86-64 (which I think was an actual error).  Wine itself uses only #pragma
pack AFAIK, so it wouldn't be affected by this change.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275