This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]