------- Comment #45 from david dot moore at intel dot com 2006-02-10 22:34
-------
The (C99) standard says:
6.7.2.1 (10) An implementation may allocate any addressable storage unit large
enough to hold a bitfield.
and
6.7.2.1 (11) As a special case, a bit-field structure member with a width of 0
indicates that no further bit-field is to be packed into the unit in which the
previous bit-field, if any, was placed.
NB -Not into a unit required by the given type (on the <type> :0 line)
So looks like 6 is the more plausible answer and the old behavior seems to be
bizarre at best. It means, in effect, that the compiler has to go back and
change its mind about the size of unit in which the previous bitfield was to be
allocated. (You can no doubt get around the use of the past tense in the
standard by suitable invocation of an oracle, or two-pass compilation - you
could also always allocate eveything in UINTS - yetch)
A more compelling argument for not changing this back is that gcc has done a
good job of being (C++) ABI compatible since 3.4. Changing this back to pre-3.4
behavior now will create an ABI break between 3.4 and 4.0.3. Even delaying the
change till 4.1 would be bad enough.
So I strongly represent that this change should not be made or, if it is made,
it should only happen under control of a flag that is off by default.
BTW, you may think I am arguing this because it would avoid having to change
the Intel compiler but actually it looks like when we changed our behavior we
did not make sure that our gcc 3.2 compatible behavior did not change, so it
looks like we have work to do anyway, and the impact of this change on our work
is perhaps an extra leg in a conditional.
So I can claim altruism here. Actually the real reason is I have been telling
people that the ABI has been very stable since 3.4 and I would rather not have
egg on my face.
--
david dot moore at intel dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |david dot moore at intel dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
