[Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

[Bug c/115109] New: Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

[luigighiron at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109

            Bug ID: 115109
           Summary: Incorrect type of enumeration constant in
                    redeclaration of enumeration constant (C23)
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: luigighiron at gmail dot com
  Target Milestone: ---

GCC does not accept the following code:

static_assert(INT_WIDTH<42&&LONG_WIDTH>=42);
enum E{a=1UL<<40,b=1};
enum E{a=1ULL<<40,b=_Generic(a,unsigned long:1,default:2)};

The static_assert is there to document the assumptions that should make this
code valid. Here is the relevant part of the standard:

> During the processing of each enumeration constant in the enumerator list,
> the type of the enumeration constant shall be:
> 
> - the previously declared type, if it is a redeclaration of the same
>   enumeration constant; or,
> 
> - the enumerated type, for an enumeration with fixed underlying type; or,
> 
> - int, if there are no previous enumeration constants in the enumerator list
>   and no explicit = with a defining integer constant expression; or,
> 
> - int, if given explicitly with = and the value of the integer constant
>   expression is representable by an int; or,
> 
> - the type of the integer constant expression, if given explicitly with = and
>   if the value of the integer constant expression is not representable by int;
>   or,
> 
>   ...
Section 6.7.3.3 "Enumeration specifiers" Paragraph 12 N3220

The types of the enumeration constants 'a' and 'b' in the first enumeration
specifier should be unsigned long and int, respectively. Then in the second
enumeration declaration, they should have the same types as the first
enumeration declaration because of the first item in the list in the above
quote. GCC does not seem to follow this and makes the type of the enumeration
constant 'a' unsigned long long because the type of the expression is unsigned
long long.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

[jsm28 at gcc dot gnu.org]

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.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

[uecker at gcc dot gnu.org]

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)

[luigighiron at gmail dot com]

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.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

[luigighiron at gmail dot com]

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.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

[uecker at gcc dot gnu.org]

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)

[uecker at gcc dot gnu.org]

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)

[uecker at gcc dot gnu.org]

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)

[cvs-commit at gcc dot gnu.org]

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.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

[clyon at gcc dot gnu.org]

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)

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

[uecker at gcc dot gnu.org]

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)

[jakub at gcc dot gnu.org]

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.