https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121938
post+gcc at ralfj dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from post+gcc at ralfj dot de ---
Uh, how this this not a bug? Is there documentation somewhere on the intended
behavior for GCC when it comes to enum sizes? The behavior I describe is with
GCC 15, so whatever changed in GCC 13 did not fix this.
I am fairly sure this is a violation of the C23 standard. There is a type that
fits the constant 18446744071562067968 (unsigned long), and therefore GCC
should use that type to represent the enum. But, strangely, it picks some
4-byte type instead.
> Enum are interesting because unsigned int is the normal type if there is no
> negative numbers. (Gcc implementation defined behavior)
GCC uses an 8-byte type when the enum consists only of a constant with value
18446744071562067967. So the documentation that claims that GCC uses unsigned
int when the values are all positive seems to be wrong.
*** This bug has been marked as a duplicate of bug 107405 ***
