https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #3 from Halalaluyafail3 <luigighiron at gmail dot com> --- (In reply to uecker from comment #2) > PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652093.html I'm confused about the tests added here: > enum H { x = 1 }; > enum H { x = 2UL + UINT_MAX }; Shouldn't this be a constraint violation if unsigned long is wide than unsigned? > If two declarations of the same type have a member-declaration or > enumerator-list, one shall not be nested within the other and both > declarations shall fulfill all requirements of compatible types (6.2.7) > with the additional requirement that corresponding members of structure or > union types shall have the same (and not merely compatible) types. Section 6.7.3.4 "Tags" Paragraph 1 N3220 I don't see anything that would require a conversion to int here, nor would I expect this to be the intent. It should just have the same value and the type will end up the same as in the previous declaration. > enum E { a = 1L, b = 2 }; > enum E { a = 1L, b = _Generic(a, enum E: 2) }; /* { dg-warning "outside the > range" } */ This just seems to be testing if int is compatible with enum E. Which from testing on godbolt is false on GCC since it would pick for enum E to be compatible with unsigned. This test also doesn't seem related to the problem which was having the types of the integral constant expressions for a be different types.
