Bit-field types in GCC vs C11 standard

Question

According to the C11 standard (mentioned in this answer), the standard forces the following types to be supported: _Bool, signed int and unsigned int. Other types can be supported but it is up to the implementation.

I tried to following code to see what are the types of the bit-fields in practice:

#include <stdint.h>
#include <assert.h>
#include <stdio.h>

#define ARG_TYPE(arg)     _Generic((arg),               \
                                _Bool          : "_Bool", \
                                char           : "char",      \
                                signed char    : "signed char",    \
                                unsigned char  : "unsigned char", \
                                short          : "short", \
                                unsigned short : "unsigned short", \
                                int            : "int", \
                                unsigned int   : "unsigned int", \
                                long           : "long", \
                                unsigned long  : "unsigned long", \
                                long long      : "long long", \
                                unsigned long long : "unsigned long long")
int main(void)
{
    struct _s
    {
        unsigned int        uval32 : 32;
        unsigned int        uval16 : 16;
        unsigned int        uval8  : 8;
        unsigned int        uval1  : 1; 
        signed int          ival32 : 32;
        signed int          ival16 : 16;
        signed int          ival8  : 8;
        signed int          ival1  : 1;
        _Bool               bool1  : 1;
    } s = {0};

    printf("The type of s.uval32 is %s\n", ARG_TYPE(s.uval32));
    printf("The type of s.uval16 is %s\n", ARG_TYPE(s.uval16));
    printf("The type of s.uval8 is %s\n", ARG_TYPE(s.uval8));
    printf("The type of s.uval1 is %s\n", ARG_TYPE(s.uval1));
    printf("The type of s.ival32 is %s\n", ARG_TYPE(s.ival32));
    printf("The type of s.ival16 is %s\n", ARG_TYPE(s.ival16));
    printf("The type of s.ival8 is %s\n", ARG_TYPE(s.ival8));
    printf("The type of s.ival1 is %s\n", ARG_TYPE(s.ival1));
    printf("The type of s.bool1 is %s\n", ARG_TYPE(s.bool1));

    (void)s;

    return 0;
}

Clang (https://godbolt.org/z/fjVRwI) and ICC (https://godbolt.org/z/yC_U8C) behaved as expected:

The type of s.uval32 is unsigned int
The type of s.uval16 is unsigned int
The type of s.uval8 is unsigned int
The type of s.uval1 is unsigned int
The type of s.ival32 is int
The type of s.ival16 is int
The type of s.ival8 is int
The type of s.ival1 is int
The type of s.bool1 is _Bool

But GCC (https://godbolt.org/z/FS89_b) introduced several issues:

1. A single bit bit-field defined other than _Bool didn't fit any of the types introduced in the _Generic:

error: '_Generic' selector of type 'unsigned char:1' is not compatible with any association

2. After commenting out the lines which issued errors I got this:

   The type of s.uval32 is unsigned int
   The type of s.uval16 is unsigned short
   The type of s.uval8 is unsigned char
   The type of s.ival32 is int
   The type of s.ival16 is short
   The type of s.ival8 is signed char
   The type of s.bool1 is _Bool
   

   To me, unsigned short, short, unsigned char and signed char are completely unexpected here.

Did I misunderstand the standard? Is this a GCC bug?

Looks like using _Generic even for well defined stuff is not portable...

Answer 1

As noted, no compiler has to provide support for oddball bit-field types. If it does, it is free to treat such types as it pleases - this is beyond the scope of the standard. You are essentially talking about the type of the abstract item referred to as "storage unit" by the standard.

Everything about this magic abstract "storage unit" is poorly-specified behavior:

C17 §6.7.2.1/11:

An implementation may allocate any addressable storage unit large enough to hold a bitfield. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.

Simply never use bit-fields anywhere and all these problems will go away. There is never a reason to use them anyhow - it is a 100% superfluous feature.

Answer 2

Yes, clang is correct here and gcc is plain wrong. The type of a bit-field is the one that is defined. Period. There is no ambiguity in the standard about this, and gcc's "feature" to have them as specific types that includes the number of specified bits is non-conforming. There has been a long discussion that starts at

https://gcc.gnu.org/ml/gcc/2016-02/msg00255.html

which basically shows that they are not willing to concede and change to a more user-friendly mode.

If you are really interested in practical aspects of this, you could just use one of the methods that force evaluation, such as + or with a comma operator. This would lose the distinction between _Bool and int bit-fields, but still could give you the distinction between long and int.