[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 uecker at gcc dot gnu.org changed: What|Removed |Added Known to work||15.0 --- Comment #12 from uecker at gcc dot gnu.org --- Fixed on trunk. https://godbolt.org/z/39cKGK9aa
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #11 from Jakub Jelinek ---
It is always good if you're testing on x86_64 to test such tests with
make check-gcc
RUNTESTFLAGS="--target_board=unix\{-m32/-mno-mmx/-mno-sse,-m32/-msse2,-m64\}
dg.exp='pr105109.c c23-tag-enum-*.c'"
or similar, that allows testing both 64-bit and 32-bit compilation and for the
latter both the variants with vector support and without (e.g. in case test
needs -Wno-psabi).
I certainly see
+FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 10)
+FAIL: gcc.dg/c23-tag-enum-6.c (test for errors, line 13)
+FAIL: gcc.dg/c23-tag-enum-7.c (test for excess errors)
+FAIL: gcc.dg/pr115109.c (test for excess errors)
on i686-linux and not on x86_64-linux and the above make check would show it
immediately, even before trying to bootstrap/regtest the patch.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #10 from uecker at gcc dot gnu.org --- Yeah, I looked at the CI before submitting and saw the three passing tests, not realizing that the fourth was stilling running. I will fix this soon.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #9 from Christophe Lyon --- Linaro CI and Intel CI have reported failures of the new tests: https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080080.html https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080078.html (Linaro precommit CI also reported the problem before the patch was committed BTW)
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #8 from GCC Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:c9b96a68860bfdee49d40b4a844af7c5ef69cd12 commit r15-1394-gc9b96a68860bfdee49d40b4a844af7c5ef69cd12 Author: Martin Uecker Date: Sat May 18 22:00:04 2024 +0200 c23: Fix for redeclared enumerator initialized with different type [PR115109] c23 specifies that the type of a redeclared enumerator is the one of the previous declaration. Convert initializers with different type accordingly and emit an error when the value does not fit. 2024-06-01 Martin Uecker PR c/115109 gcc/c/ * c-decl.cc (build_enumerator): When redeclaring an enumerator convert value to previous type. For redeclared enumerators use underlying type for computing the next value. gcc/testsuite/ * gcc.dg/pr115109.c: New test. * gcc.dg/c23-tag-enum-6.c: New test. * gcc.dg/c23-tag-enum-7.c: New test.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #7 from uecker at gcc dot gnu.org --- PATCH v2 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652109.html
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #6 from uecker at gcc dot gnu.org --- But it shows that the logic is still not right for the case where all the final types should be int.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #5 from uecker at gcc dot gnu.org --- Right, included the wrong test... The conversion seems right, if we have a predefined type. For enums with fixed underlying type we then have a constraint violation if the value does not fit. This may have been the intention also here, but it is not entirely clear. I made an -Woverflow warning for now, so it behaves similar to other initialization of constants and a warning is all that is required here. If the final value ends up the same, the types are compatible so this part is then fine.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #4 from Halalaluyafail3 ---
(In reply to Halalaluyafail3 from comment #3)
> enum E { a = 1L, b = _Generic(a, enum E: 2) }; /* { dg-warning "outside the
> range" } */
Seems like I copied this wrong, the comment should be a part of the first
quote.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #3 from Halalaluyafail3 ---
(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.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 --- Comment #2 from uecker at gcc dot gnu.org --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652093.html
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||uecker at gcc dot gnu.org Last reconfirmed||2024-05-16 Ever confirmed|0 |1 --- Comment #1 from Joseph S. Myers --- Adding Martin as an issue related to redefinitions of tagged types.
