Re: [Tinycc-devel] Ready for Release 0.9.27

[Vincent Lefevre]

On 2017-02-09 21:01:11 +0000, Thomas Preud'homme wrote:
> On jeudi 9 février 2017 18:40:13 GMT grischka wrote:
> > Vincent Lefevre wrote:
> > > The C standard says:
> > >   6.3.1.1 Boolean, characters, and integers
> > >   
> > >   [...]
> > >   
> > >   If an int can represent all values of the original type (as
> > >   restricted by the width, for a bit-field), the value is converted
> > >   to an int; otherwise, it is converted to an unsigned int. These are
> > >   called the integer promotions.58) All other types are unchanged by
> > >   the integer promotions.
> > > 
> > > In my example of my Debian bug report:
> > >   struct { unsigned int a:3; } s = { 1 };
> > >   
> > >   s.a - 2
> > > 
> > > The original type (a 3-bit unsigned bit-field) contains the values
> > > from 0 to 7. An int can represent all of them. Thus s.a is converted
> > > to an int, and s.a - 2 gives -1 (as an int).
> > > 
> > > But according to the test, tcc seems to regard s.a - 2 as
> > > (unsigned int) (-1), i.e. UINT_MAX. However, tcc behaves correctly
> > > on ((unsigned char) 1 - 2), giving -1.
> > > 
> > > Note that GCC 6.3.0, ICC 15.0.0 and Clang 3.9.1 are correct on this
> > > test.
> > 
> > But note that MSVC still behaves like tcc, and that such behavior

MSVC is a C++ compiler. The rules with old C++ standards might be
different (possibly not intentionally). It seems to be confirmed
by <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1260.htm>:

  For C++, other integral and enumeration types are allowed for
  bit-fields; it is explicit that bit-fields do not have special types
  ([class.bit], "The bit-field attribute is not part of the type of
  the class member.").

> > can be seen compliant to the standard too, at least before the rather
> > recent addition of the
> > 
> >     ... (as restricted by the width, for a bit-field) ...
> > 
> > phrase, with the result that now basically every possible ':X' field-width
> > is supposed to define its own integral C type.
> 
> Indeed, this parenthesis is not prosent in C99. Without this it reads as if 
> the original type is the base type of the bitfield. Since tcc aims at C99 
> conformance I agree with grischka this is a "won't fix".

No, this is not really a change of the standard, but a clarification.
See: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_315.htm

  Last sentence of paragraph 2 of 6.3.1.1, add the words as restricted
  by the width, for a bit-field as follows:

    If an int can represent all values of the original type (as
    restricted by the width, for a bit-field), the type is converted
    to an int;

This has been done for C11.

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.

FYI, GCC 6 behaves in the same way with -std=c89, -std=c99 and -std=c11.
Ditto for Clang 3.9.

-- 
Vincent Lefèvre <address@hidden> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)