Re: Help with bit-field semantics in C and C++

[Geoffrey Keating <geoffk at geoffk dot org>]

Roger Sayle <roger@eyesopen.com> writes:

> Could one of GCC's resident C/C++ language lawyers confirm that the
> behaviour of the following code is undefined?
> 
> 
> extern "C" void abort(void);
> 
> enum E { e = 0x0f };
> 
> void test(int n)
> {
>   enum E x, y;
> 
>   x = (E)0x10;
>   y = (E)n;
> 
>   if (x != y)
>     abort ();
> }
> 
> int main()
> {
>   test(0x10);
>   return 0;
> }
> 
> 
> Normally, when storing a narrower mode within a wider one, GCC's RTL
> supports one of three representations: zero extended, sign extended
> and paradoxical.  I'd just like confirmation that C/C++ bitfields
> are intended to use a paradoxical representation.

There aren't any bitfields in your example.

As far as I can tell, the code is valid C or C++, at least on all
machines that GCC runs on.  The type of 'enum E' will be compatible
with 'char' or 'int', depending on flag settings.

> Hence optimizations such as "(x > e)" -> false, which are valid
> for sign and zero extended types, are invalid when TYPE_PRECISION(t)
> != GET_MODE_BITSIZE(GET_MODE(t)).
> 
> In the above code, should we be truncating the immediate mode constant
> to zero, if we're not truncating the variable assignment?  Do tree
> types need an extra bit to indicate "paradoxical" or is the test
> that "TYPE_PRECISION(t) != GET_MODE_BITSIZE(GET_MODE(t))" sufficient.
> One can imagine the middle-end needing to support narrow bit types
> in other languages whose semantics may require explicit sign or zero
> extension.

I think you sent the wrong example.