[PATCH] Add support for -funsigned-bitfields

[Artyom Skrobov]

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