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 <vinc...@vinc17.net> - 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) _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel