This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Help with bit-field semantics in C and C++
- From: Roger Sayle <roger at eyesopen dot com>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 23 Aug 2004 16:58:26 -0600 (MDT)
- Subject: Help with bit-field semantics in C and C++
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.
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.
Many thanks in advance,
Roger
--