* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
@ 2024-05-16 20:58 ` jsm28 at gcc dot gnu.org
2024-05-18 20:20 ` uecker at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2024-05-16 20:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
Joseph S. Myers <jsm28 at gcc dot gnu.org> 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 <jsm28 at gcc dot gnu.org> ---
Adding Martin as an issue related to redefinitions of tagged types.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
2024-05-16 20:58 ` [Bug c/115109] " jsm28 at gcc dot gnu.org
@ 2024-05-18 20:20 ` uecker at gcc dot gnu.org
2024-05-19 1:48 ` luigighiron at gmail dot com
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: uecker at gcc dot gnu.org @ 2024-05-18 20:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
2024-05-16 20:58 ` [Bug c/115109] " jsm28 at gcc dot gnu.org
2024-05-18 20:20 ` uecker at gcc dot gnu.org
@ 2024-05-19 1:48 ` luigighiron at gmail dot com
2024-05-19 2:22 ` luigighiron at gmail dot com
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: luigighiron at gmail dot com @ 2024-05-19 1:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
` (2 preceding siblings ...)
2024-05-19 1:48 ` luigighiron at gmail dot com
@ 2024-05-19 2:22 ` luigighiron at gmail dot com
2024-05-19 6:24 ` uecker at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: luigighiron at gmail dot com @ 2024-05-19 2:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #4 from Halalaluyafail3 <luigighiron at gmail dot com> ---
(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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
` (3 preceding siblings ...)
2024-05-19 2:22 ` luigighiron at gmail dot com
@ 2024-05-19 6:24 ` uecker at gcc dot gnu.org
2024-05-19 6:44 ` uecker at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: uecker at gcc dot gnu.org @ 2024-05-19 6:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
` (4 preceding siblings ...)
2024-05-19 6:24 ` uecker at gcc dot gnu.org
@ 2024-05-19 6:44 ` uecker at gcc dot gnu.org
2024-05-19 11:08 ` uecker at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: uecker at gcc dot gnu.org @ 2024-05-19 6:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
` (5 preceding siblings ...)
2024-05-19 6:44 ` uecker at gcc dot gnu.org
@ 2024-05-19 11:08 ` uecker at gcc dot gnu.org
2024-06-18 10:51 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: uecker at gcc dot gnu.org @ 2024-05-19 11:08 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
` (6 preceding siblings ...)
2024-05-19 11:08 ` uecker at gcc dot gnu.org
@ 2024-06-18 10:51 ` cvs-commit at gcc dot gnu.org
2024-06-19 7:56 ` clyon at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-06-18 10:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Uecker <uecker@gcc.gnu.org>:
https://gcc.gnu.org/g:c9b96a68860bfdee49d40b4a844af7c5ef69cd12
commit r15-1394-gc9b96a68860bfdee49d40b4a844af7c5ef69cd12
Author: Martin Uecker <uecker@tugraz.at>
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 <uecker@tugraz.at>
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
` (7 preceding siblings ...)
2024-06-18 10:51 ` cvs-commit at gcc dot gnu.org
@ 2024-06-19 7:56 ` clyon at gcc dot gnu.org
2024-06-19 8:09 ` uecker at gcc dot gnu.org
2024-06-19 8:17 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: clyon at gcc dot gnu.org @ 2024-06-19 7:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
Christophe Lyon <clyon at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clyon at gcc dot gnu.org
--- Comment #9 from Christophe Lyon <clyon at gcc dot gnu.org> ---
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)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
` (8 preceding siblings ...)
2024-06-19 7:56 ` clyon at gcc dot gnu.org
@ 2024-06-19 8:09 ` uecker at gcc dot gnu.org
2024-06-19 8:17 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: uecker at gcc dot gnu.org @ 2024-06-19 8:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
2024-05-15 17:16 [Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23) luigighiron at gmail dot com
` (9 preceding siblings ...)
2024-06-19 8:09 ` uecker at gcc dot gnu.org
@ 2024-06-19 8:17 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-06-19 8:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 12+ messages in thread