Re: Bit-field patch, resurrected

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Wed, 14 Apr 2004, Jim Wilson wrote:

> Changing expand_expr this way seems fragile.  It requires that anyone 
> modifying expand_expr remember that they must call REDUCE_BIT_FIELD if 
> they add a return statement, and of course people will forget to do 
> this, which means this support will break occasionally.

I arrived at this approach because I concluded that the trees being sent
to expr.c (for bf64-1.c) were correct and so the middle-end should handle
them (and anything done before then might get optimized away).  Liking
even less the idea of having a separate integer RTL mode for every
bit-field width, I arrived at these explicit checks.
<http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00651.html> describes the
problems with bf64-1.c (and attracted no comments on alternative
implementation approaches).

> I have another problem with this, which is that I believe this breaks 
> the C89 support.  C99 defines the usual arithmetic promotions to say 
> that if we have two integer types, we promote to the one with greater 
> rank.  Thus if we have two bitfields, we promote the smaller bitfield to 
> the larger one.  Thus the REDUCE_BIT_FIELD stuff is necessary for 
> correct C99 support.  C89 however says nothing about bitfields.  It just 
> says that we promote to which ever standard integer type can hold the 
> value.  That means if we have two bitfields, we promote to int (assuming 
> both are smaller than int).  Thus the REDUCE_BIT_FIELD stuff is wrong 
> for C89.  I don't have a copy of the C90 standard, but I would be 
> surprised if it was different than C89 in this area.  Thus your 
> REDUCE_BIT_FIELD stuff is also wrong for C90.

All the REDUCE_BIT_FIELD stuff is only relevant for bit-field types wider 
than int.  All narrower ones generate arithmetic on int / unsigned int 
rather than on the bit-field type - the types get promoted earlier, 
according to whether int can hold all the values of the bit-field type.  
Part of the point of this patch is to get such promotions correct, but the 
issues for wider types turned up because of a bf64-1.c failure.  How 
bit-field promotion works in C90 is confirmed in DR#015 (and DR#122).

In C99, implementation-defined types are permitted for bit-fields (and we
sort-of permit long long etc. as such - pedwarn for them as extensions if
pedantic).  In C90, they aren't mentioned (though the restrictions on
bit-field type in C90 aren't in the Constraints so don't need diagnostics;
we give them anyway).  Clearly we ought to give them the proper semantics
when we do permit them; C99 is clear on how wider bit-fields should work
(by virtue of the rank rules), C90 is silent.

> This issue perhaps explains why your patches did not work for C++ and 
> Java, as they are based on the C90 standard, and hence they probably 
> don't have the same bit-field aware promotion rules that C99 has.

In C++, bit-fields have narrow (or wide) representations but don't have a
special type [class.bit].  An unsigned:1 bit-field is an unsigned int in
C++ but promotes to int in C.  C++ doesn't deal with types wider than int
at all (bit-fields wider than int are allowed but the rest is padding) but
presumably we should treat a long long:52 bit-field in C++ as having type
long long (not a special type).

-- 
Joseph S. Myers
jsm@polyomino.org.uk