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: "matz at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Jan 2006 15:14:28 -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 #23 from matz at suse dot de 2006-01-16 15:14 -------
The x86-64 ABI itself doesn't talk about zero-sized bitfields. So both
behaviours are correct regarding the ABI. It talks about unnamed bitfields
(which zero-sized ones must be) not influencing the overall alignment
of structures or unions, but the problem here is different.
Having said that I agree with Marks mail on gcc@ that the pre-3.4 behaviour
made more sense. Unfortunately I'm also no stor-layout.c expert, so
can't really comment on how the best approach is to implement it. I assume
Jason would be the best to comment here, as he changed that behaviour.
Stevens latest patch changes the evaluation of EMPTY_FIELD_BOUNDARY vs.
PCC_BITFIELD_TYPE_MATTERS, so someone needs to make sure that this is okay.
Additionally I don't know how stor-layout tracks alignment, i.e. if
desired_align contains the alignment for the _current_ field, or for the
_next_ field. A zero-sized bitfield should influence alignment of the
next field (although due to the size of zero this shouldn't make a
difference).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275