https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107917
Bug ID: 107917
Summary: [13 regression?] Size of enum type doesn't match size
of enum value
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: luis.machado at arm dot com
Target Milestone: ---
I noticed this with both arm-none-eabi-gcc and arm-none-linux-gnueabihf-gcc,
version 13 ((20d2a8c24f3ca487ffd35fefcc9b1562bb10b609).
While attempting to build the Linux Kernel for 32-bit arm, I kept running into
the following assertion:
linux/drivers/ata/libahci.c: In function 'ahci_led_store':
linux/include/linux/compiler_types.h:357:45: error: call to
'__compiletime_assert_302' declared with attribute error: BUILD_BUG_ON failed:
sizeof(_s) > sizeof(long)
357 | _compiletime_assert(condition, msg, __compiletime_assert_,
__COUNTER__)
The context is we're passing a enum value (_s) that is part of an enum type
also defining (1 << 31). Supposedly the presence of a enum value (1 << 31)
makes gcc bump the size of the enum type to 64-bit.
This can be reproduced with the following:
enum {
A = 1 <<31,
B = 0xffffffff,
} e;
int s1 = sizeof(A);
int s2 = sizeof(B);
int s3 = sizeof(e);
Check the output on godbolt: https://godbolt.org/z/YaK3E8jEc
For gcc 13:
s3:
.word 8
s2:
.word 8
s1:
.word 8
e:
For gcc 12.2:
e:
s1:
.word 4
s2:
.word 8
s3:
.word 8
It is not completely clear if this change in behavior was intended or not. It
certainly diverges from what gcc did before and what clang does currently.
