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

["steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #34 from steven at gcc dot gnu dot org  2006-01-19 17:40 -------
I looked up a few links to see how people use zero-length bit-fields and what
semantics they're expecting.  I mostly found links to compiler documentation
about how other compilers interpret these bit-fields. Perhaps we can verify
that GCC 4.1 with a patch for this bug satisfies those expectations.  If they
don't, perhaps those deviations should be mentioned explicitly in the release
notes and the manual.


Intel ICC behavior was already noted in comment #14.


IBM (XLC):
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.vacpp7a.doc/proguide/ref/calgnbit.htm
"A zero-length bit field pads to the next alignment boundary of its base
declared type. This causes the next member to begin on a 4-byte boundary for
all types except long in 64-bit mode and long long in both 32-bit and 64-bit
mode, which will move the next member to the next 8-byte boundary. Padding does
not occur if the previous member's memory layout ended on the appropriate
boundary."

And the rules from "Rules for bit-packed alignment" in the "XL C/C++ Advanced
Edition for LinuxProgramming Guide Version 7.0" state for bit-packed structs:
"If a zero-length bit field is the first member of an aggregate, it has no
effect on boundary. If the zero-length bit field is already at a byte boundary,
the next member starts at this boundary. A non-bit field member that follows a
bit field is aligned on the next bit boundary."  I don't know if bit-packed is
the same as just "packed" in GCC.


Microsoft:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/class_34.asp
Has an example saying "unsigned " 0;    // Force alignment to next boundary.",
which is not very specific (but better than nothing I guess).


HP, HP C manual for VAX and other older HP systems IIUC
(http://docs.hp.com/en/B3901-90012/ch02s01.html):
"zero-length bit-fields force the following member to the next natural
boundary."

And from HP's "Itanium Software Conventions and Runtime Architecture"
(http://www.desktalk.com/drc/resources/ia64rt-12-gen.pdf):
"Zero-length bit fields force the alignment of the following member of a
structure to the next alignment boundary corresponding to the type of the
bit field. An unnamed zero-length bit field, however, will not force the
external alignment of the structure to that boundary."

And last but not least, HP's OpenVMS C compiler
(http://h71000.www7.hp.com/commercial/c/docs/6180p012.html#index_x_361):
"If the bit field is assigned a width of 0, it indicates that no further bit
fields should be placed in the alignment unit[.] (...) As a special case, an
unnamed [bit-]field of width 0 causes the next member (normally another field)
to be aligned on at least a byte boundary; that is, a bit-field structure
member with zero width indicates that no further bit field should be packed
into an alignment unit. (...) [T]he second is zero bits wide, which forces the
next member to be aligned on a natural or byte boundary."

So in summary:
- Intel 9.0 is just as buggy as GCC 3.4 and GCC 4.0 because it apparently
  tries to even mimick GCC bugs now.  I think ICC/GCC compatibility is
  relevant but we can't stop fixing our bugs because Intel adopts them too.
  (Besides, we don't know what ICC does on x86-64 and for e.g. long long).
- 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.


I also found this post from Mark M. about PCC_BITFIELD_TYPE_MATTERS which may
be of interest: http://gcc.gnu.org/ml/gcc/2002-12/msg01324.html.  This is the
first time I've seen the purpose of PCC_BITFIELD_TYPE_MATTERS in a way that I
can understand ;-)


-- 


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