Vincent Lefevre wrote:
Note that according to C99, a bit-field is a type ("unsigned int" here
is just a type specifier). Just like an array is not the same type of
the type of its elements. See 6.7.2.1p9 in C99:
A bit-field is interpreted as a signed or unsigned integer type
consisting of the specified number of bits.107) [...]
107) As specified in 6.7.2 above, if the actual type specifier
used is int or a typedef-name defined as int, then it is
implementation-defined whether the bit-field is signed or
unsigned.
When interpreting the standard, it is important to consider the
*whole* standard, not just individual sentences, which may be
ambiguous.
If that were true then all your citations wouldn't prove anything ;)
FYI, GCC 6 behaves in the same way with -std=c89, -std=c99 and -std=c11.
Ditto for Clang 3.9.
I wouldn't really mind if we change the behavior.
Basically tccgen.c contains 8 lines (in gen_op/expr_cond) similar to
if ((t1 & (VT_BTYPE | VT_UNSIGNED)) == (VT_LLONG | VT_UNSIGNED) ...
if ((t1 & (VT_BTYPE | VT_UNSIGNED)) == (VT_INT | VT_UNSIGNED) ...
Maybe we just need to change these like this
if ((t1 & (VT_BTYPE | VT_UNSIGNED | VT_BITFIELD)) == ....
Note that VT_BITFIELD set implies bit-field width < original type width.
--- grischka
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
