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

[Geoff Keating <geoffk at geoffk dot org>]

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature