Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 14 Jan 2008, Richard Guenther wrote:

>  - document how integral promotion is performed on the implementation
>    defined bitfields we allow as a GNU extension.  (4.9, "Integer
>    promotion rules are extended for non-standard bit-field types to
>    promote to the smallest integer type that can represent all values
>    of the bit-field type.")

Once you define bit-fields to have their own types as explained in the C90 
DRs and apparently intended in the C99 textual history, everything about 
integer promotions follows from the standard (via the rules on integer 
promotion rank which assign ranks to all those types).  If you don't 
define that, other issues arise with no existing standard text to resolve 
them, see <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1260.htm>.

Thus I think we should:

* Admit in the documentation that we really do have extended integer types 
- one signed and one unsigned for each precision for which bit-fields are 
allowed, other than those for which there are standard types.

* Say that bit-fields are assigned such types.

* Make the gimplifier (or a later tree-ssa pass) insert whatever 
conversions / reductions in precision may be needed to produce trees 
acceptable to expand, if you think expand can't handle the special types 
reliably.  In particular, for arithmetic on such types and on all 
conversions to such types.  (Without special types, special code is still 
needed for assignments to bit-fields, no longer handled as conversions.)

* If C1x chooses an approach more like C++ than the C90 DRs to bit-field 
types, then make the C front end act more like the C++ front end does when 
in C1x mode.

-- 
Joseph S. Myers
joseph@codesourcery.com