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

[Geoff Keating]

On Aug 24, 2004, at 2:20 PM, Roger Sayle wrote:

>
> On 24 Aug 2004, Geoffrey Keating wrote:
>> Roger Sayle <roger@eyesopen.com> writes:
>>> 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.
>
>
> My apologies.  Joseph Myers and Mark Mitchell have already pointed
> out the I've used the wrong terminology.  The g++ front-end treats
> C++ enumerators as "bit-sized" integers.  These are not the same
> to language lawyers as bit-fields.  In the middle-end, however, they
> are treated similarly.
>
> The example code I posted will "abort()" with g++ 3.4 and mainline,
> but executes to completion with gcc-3.3.3 and all earlier versions.
> It also works fine with Intel icc.
>
>
>>> 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.
>
> No this is the one I intended to send.  In the example above, when
> compiled with mainline, TYPE_PRECISION(t) != 
> GET_MODE_BITSIZE(GET_MODE(t)).

I see.

As others have pointed out, this is not actually fully conforming C++, 
because of 7.2/9.  However, it is fully conforming C.

It's interesting that you mention bitfields.  I believe that's a case 
where the mode's bitsize is not the same as the precision of the 
bitfield's type, but the bitfield must be sign- or zero- extended.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2410 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20040824/41ca5a4a/attachment.p7s>