Issue 177796
Summary [Clang] Clang does not report when an enumerated type may be truncated by a bitfield.
Labels clang
Assignees
Reporter F-OS
    Clang does not report when an enumerated type may be truncated by a bitfield, unlike GCC.

The following test code: 
```

#include <stdint.h>
typedef enum {
  FLAG_A = 0,
  FLAG_B = 1,
  FLAG_C = 2
} flags_t;
typedef struct test {
  uint64_t data : 63;
  flags_t flags : 1;
} test;

```
When compiled under GCC 13.3.0 on Ubuntu 24.04.2 LTS with the following command line:
`gcc -Wall -std=c11 -c ex.c`
Will report this error:
```

ex.c:9:11: warning: flags is narrower than values of its type
    9 |   flags_t flags : 1;
      |           ^~~~~

````
However, when compiled under clang with the version string:
`
Ubuntu clang version 22.0.0 (++20260105081943+212527c00ba6-1~exp1~20260105082109.1379)
`
And the command line:
`clang-22 -Weverything --std=c11 -c ex.c`
Only the following errors are reported:
```
ex.c:9:11: warning: bit-field 'flags' of type 'flags_t' has a different storage size than the preceding bit-field (4 vs 8 bytes)
      and will not be packed under the Microsoft ABI [-Wms-bitfield-padding]
    9 |   flags_t flags : 1;
      | ^
ex.c:8:12: note: preceding bit-field 'data' declared here with type 'uint64_t' (aka 'unsigned long')
    8 |   uint64_t data : 63;
      | ^
ex.c:10:8: warning: no newline at end of file [-Wnewline-eof]
   10 | } test;
      |        ^
2 warnings generated.
```
This not seem relevant to the issue GCC reported.

The standard states (ISO/IEC 9899:201x Section 6.7.2.2, paragraph 4, could only find the draft):
> Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type... but shall be capable of representing the values of all the members of the enumeration.

I would assume this prohibits an enumerated type being stored in a bitfield which is not wide enough to store all possible values and warrants a compiler warning.

In searching for duplicate issues I found the [following](https://github.com/llvm/llvm-project/issues/3979). This issue does not seem relevant.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to