This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
- From: "mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 19 Jan 2006 19:14:11 -0000
- Subject: [Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
- References: <bug-22275-3760@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #35 from mark at codesourcery dot com 2006-01-19 19:14 -------
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
steven at gcc dot gnu dot org wrote:
> - Older HP compilers and MS compilers use zero-length bit-fields to force
> the following member of a struct to the next natural (is that GCC's
> BITS_PER_WORD?) boundary.
> - XLC and HP on IA-64 force alignment corresponding to the type of the bit
> field, of which IBM says it is essentially the same, but this is not true
> for GCC with e.g. long long on ix86.
That's essentially the PCC_BITFIELD_TYPE_MATTERS distinction; the HP/MS
compilers in the first bullet point are not using the pcc-style bitfields.
Your research is interesting. However, I'm not too worried about our
handling of zero-width bitfields by themselves; the various psABIs
specify that behavior, so we have a clear guideline. It's when we throw
in various GCC extensions (#pragma pack, __attribute__((aligned)), etc.)
that it gets complicated and hard.
I'm hoping that since Michael and I independently came to the same
conclusion about how things should work, and since there were no
objections to my initial proposal to change things back on the mailing
list, we're actually pretty close to a patch. Michael, do you plan to
revise your patch to implement the semantics on which we've agreed?
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275