A bug in GCC implementation of bit-fields

Question

Working in C11, the following struct:

struct S {
  unsigned a : 4;
  _Bool    b : 1;
};

Gets layed out by GCC as an unsigned (4 bytes) of which 4 bits are used, followed by a _Bool (4 bytes) of which 1 bit is used, for a total size of 8 bytes.

Note that C99 and C11 specifically permit _Bool as a bit-field member. The C11 standard (and probably C99 too) also states under §6.7.2.1 'Structure and union specifiers' ¶11 that:

An implementation may allocate any addressable storage unit large enough to hold a bit-field. 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.

So I believe that the member b above should have been packed into the storage unit allocated for the member a, resulting in a struct of total size 4 bytes.

GCC behaves correctly and packing does occur when using the same types for the two members, or when one is unsigned and the other signed, but the types unsigned and _Bool seem to be considered too distinct by GCC for it to handle them correctly.

Can someone confirm my interpretation of the standard, and that this is indeed a GCC bug?

I'm also interested in a work-around (some compiler switch, pragma, __attribute__...).

I'm using gcc 4.7.0 with -std=c11 (although other settings show the same behavior.)

Note that the GCC extension `__attribute__ ((packed))` can be applied to the members here, but is orthogonal to this problem (it results in a struct of size 4 + 1 = 5, i.e. with the same issue.) — ndkrempel, Jul 01 '12 at 15:17
Related: http://stackoverflow.com/questions/308364/c-bitfield-packing-with-bools (but refers to C++, which isn't quite as exacting in its wording on bit-fields.) — ndkrempel, Jul 01 '12 at 15:28
According to an answer to the question linked above, this behavior didn't occur in gcc 4.2.4, so may be a regression since then. — ndkrempel, Jul 01 '12 at 15:35
After some further research, it looks like this behavior might be specific to GCC on Windows, as it tries to match the behavior of MSVC. Still interested in work-around to disable this. — ndkrempel, Jul 01 '12 at 15:50

ndkrempel · Accepted Answer · 2015-12-15T02:52:18.567

10

The described behavior is incompatible with the C99 and C11 standards, but is provided for binary compatibility with the MSVC compiler (which has unusual struct packing behavior.)

Fortunately, it can be disabled either in the code with __attribute__((gcc_struct)) applied to the struct, or with the command-line switch -mno-ms-bitfields (see the documentation).

edited Dec 15 '15 at 02:52

answered Jul 01 '12 at 15:56

ndkrempel

1,906
14
18

Is this documented anywhere? I can't seem to find anything useful on `mno-ms-bitfields` – Shafik Yaghmour Oct 21 '15 at 15:00
Thank you, not sure why I could not find that before. It would useful to edit that into your answer since comments are not meant to be long-term. – Shafik Yaghmour Dec 04 '15 at 13:20
Should be fixed in GCC >= 8. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 – benjarobin May 09 '22 at 13:47

score 0 · Answer 2 · answered Jul 01 '12 at 17:16

Using both GCC 4.7.1 (home-built) and GCC 4.2.1 (LLVM/clang†) on Mac OS X 10.7.4 with a 64-bit compilation, this code yields 4 in -std=c99 mode:

#include <stdio.h>

int main(void)
{
    struct S
    {
        unsigned a : 4;
        _Bool    b : 1;
    };
    printf("%zu\n", sizeof(struct S));
    return 0;
}

That's half the size you're reporting on Windows. It seems surprisingly large to me (I would expect it to be size of 1 byte), but the rules of the platform are what they are. Basically, the compiler is not obliged to follow the rules you'd like; it may follow the rules of the platform it is run on, and where it has the chance, it may even define the rules of the platform it is run on.

This following program has mildly dubious behaviour (because it accesses u.i after u.s was last written to), but shows that the field a is stored in the 4 least significant bits and the field b is stored in the next bit:

#include <stdio.h>

int main(void)
{
    union
    {
        struct S
        {
            unsigned a : 4;
            _Bool    b : 1;
        } s;
        int i;
    } u;
    u.i = 0;
    u.s.a = 5;
    u.s.b = 1;
    printf("%zu\n", sizeof(struct S));
    printf("%zu\n", sizeof(u));
    printf("0x%08X\n", u.i);
    u.s.a = 0xC;
    u.s.b = 1;
    printf("0x%08X\n", u.i);
    return 0;
}

Output:

† i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)

A bug in GCC implementation of bit-fields

2 Answers2

Linked