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 > 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". Best regards, Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel