This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend
On Tue, 15 Jan 2008, Michael Matz wrote:
> Doing arithmetic on small bit-fields on the (larger) promoted type, but
> doing them on large bit-fields on the exact width creates an asymmetry.
It's the same as arithmetic on unsigned short actually being done on the
promoted type (signed int), while arithmetic on unsigned int involves no
promotion.
> That asymmetry then reflects into the code generator as ugly special
> cases, and actually also in horrible intermediate code (like doing bit
> mask operations after all arithmetic).
Bit-fields generally give bad code, and masking when loading and storing
will generally be needed, and if the result of arithmetic is being stored
back in a bit-field of the same width then no further masking should be
needed for addition/subtraction/multiplication than that on loads and
stores (you can always do those operations on wider types then reduce).
> So, if there's opportunity to fix the C standard in the next round by
> including language for promotions wider than int, that would be IMO much
> better than introducing first-class bit-field types. It would also mirror
> current behaviour of many compilers.
There have been vague suggestions of introducing requirements-based types
(where the programmer would specify bits / representation / range /
overflow handling etc.) in future, so anything affecting bit-fields
doesn't avoid the possibility of such types as true first-class types
(that can be used for toplevel object declarations, not just in
structures).
--
Joseph S. Myers
joseph@codesourcery.com