This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]