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 [EMAIL PROTECTED]
