| 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