> This patch is not quite correct. Given:
>
> typedef int A;
> typedef signed int B;
> struct S { A a : 1; B b : 1; };
>
> ... -funsigned-bitfields should give 'a' an unsigned
> type and 'b' a signed type.Yes, you're right, and GCC does handle such cases. Apparently, even more plumbing is needed here than I thought... > In C++, this is non-conforming -- 'plain' bitfields are > required to be signed in C++, since otherwise you would > get incoherent behavior inside class templates -- and > I'd like us to reject the flag in C++ mode unless > there's some strong compatibility argument. As of C++11, 9.6.3 still stated that "It is implementation-defined whether a plain (neither explicitly signed nor unsigned) char, short, int, long, or long long bit-field is signed or unsigned"; therefore, C++ code relying on -funsigned-bitfields is legal for both -std=c++11 and -std=c++98 C++1y does indeed forbid such implementation, so the flag will need to be rejected in -std=c++1y > In C99 onwards, this behavior is conforming but makes > no sense in some cases, since the same typedef can be > redeclared with and without an explicit 'signed' type > specifier. We should diagnose such cases. Yes, such diagnostic would be helpful, but IMO not strictly necessary: the implementation-defined-ness (in C99, any bitfield other than _Bool, signed int, and unsigned int, is implementation-defined per 6.7.2.1.4) allows for any of the alternative declarations to be used. In particular, GCC doesn't diagnose such cases, and the last redeclaration is the one that takes effect. > What is the motivation for allowing this? Compatibility with GCC and other compilers that allow both options. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
