[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Ready for Release 0.9.27

From: grischka
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27
Date: Fri, 10 Feb 2017 08:42:40 +0100
User-agent: Thunderbird (Windows/20090812)

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

When interpreting the standard, it is important to consider the
*whole* standard, not just individual sentences, which may be

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]