[Bug c/107405] New: enums can be long in gcc-13

[Bug c/107405] New: enums can be long in gcc-13

[jirislaby at gmail dot com]

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

            Bug ID: 107405
           Summary: enums can be long in gcc-13
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jirislaby at gmail dot com
  Target Milestone: ---

While compiling the kernel (next/master -- 89bf6e28373beef9) with gcc-13, I
see:
drivers/block/mtip32xx/mtip32xx.c:722:25: error: format '%x' expects argument
of type 'unsigned int', but argument 3 has type 'long in' [-Werror=format=]

That is:
enum {
Many members, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/ata.h?id=4dc12f37a8e98e1dca5521c14625c869537b50b6#n25
};
...
#define PORT_IRQ_HANDLED \      
        (PORT_IRQ_SDB_FIS | PORT_IRQ_LEGACY | \
         PORT_IRQ_TF_ERR | PORT_IRQ_IF_ERR | \
         PORT_IRQ_CONNECT | PORT_IRQ_PHYRDY)


...
u32 port_stat;
...
        dev_warn(&dd->pdev->dev,
              "Port stat errors %x unhandled\n",
              (port_stat & ~PORT_IRQ_HANDLED));

So port_stat is uint, ~PORT_IRQ_HANDLED is derived from enum, which should be
int from standard.

Reduced testcase:
#include <stdio.h>
enum { A = 0xffffffff, B = 1 << 31, };
int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }

$ gcc-13 -std=gnu99 x.c -Wall -O2 && ./a.out
x.c: In function ‘main’:
x.c:3:27: warning: format ‘%x’ expects argument of type ‘unsigned int’, but
argument 3 has type ‘long int’ [-Wformat=]
    3 | int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
      |                          ~^            ~
      |                           |            |
      |                           unsigned int long int
      |                          %lx
ffffffff 80000000 8
$ gcc-12 -std=gnu11 x.c -Wall -O2 && ./a.out
ffffffff 80000000 4

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jirislaby at gmail dot com]

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

--- Comment #1 from Jiri Slaby <jirislaby at gmail dot com> ---
(In reply to Jiri Slaby from comment #0)
> Reduced testcase:
> #include <stdio.h>
> enum { A = 0xffffffff, B = 1 << 31, };
> int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }

It's also interesting to me, that A is long even with gcc-12...

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=107314

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Note there's a similar issue I sent patch for:
https://lore.kernel.org/all/f70c7a11-e81e-f6b9-a403-315117f4aa3a@suse.cz/

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-10-26

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
> enum { A = 0xffffffff, B = 1 << 31, };
> int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
> 

Apparently, 0xffffffff is treated by the compiler as unsigned int constant and
thus it likely leads to the promotion to a longer interger. Joseph will explain
better. If you use -1, it's fine:

enum { A = -1, B = 1 << 31, };
int main() { printf("%x %x %zu\n", A, B, sizeof(B)); }

$ gcc pr107405.c -Wall && ./a.out
ffffffff 80000000 4

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jirislaby at gmail dot com]

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

--- Comment #4 from Jiri Slaby <jirislaby at gmail dot com> ---
(In reply to Martin Liška from comment #3)
> > enum { A = 0xffffffff, B = 1 << 31, };
> > int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
> > 
> 
> Apparently, 0xffffffff is treated by the compiler as unsigned int constant
> and thus it likely leads to the promotion to a longer interger.

The problem is that is breaks existing code (which will be barely fixed as this
is clearly gcc-13's bug (or change of behavior at least)).

Another question is why B is affected by A at all? Also sizeof of that enum (if
one gives it a name) is 8 with gcc-13. That is not allowed by the standard,
IMO.

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jirislaby at gmail dot com]

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

--- Comment #5 from Jiri Slaby <jirislaby at gmail dot com> ---
(In reply to Jiri Slaby from comment #4)
> Also sizeof of that enum
> (if one gives it a name) is 8 with gcc-13. That is not allowed by the
> standard, IMO.

I'm correcting myself, this was always the case and is not new in 13. With
-pedantic, I can see at last:
x.c:3:13: warning: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jiri Slaby from comment #4)
> (In reply to Martin Liška from comment #3)
> > > enum { A = 0xffffffff, B = 1 << 31, };
> > > int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
> > > 
> > 
> > Apparently, 0xffffffff is treated by the compiler as unsigned int constant
> > and thus it likely leads to the promotion to a longer interger.
> 
> The problem is that is breaks existing code (which will be barely fixed as
> this is clearly gcc-13's bug (or change of behavior at least)).
> 
> Another question is why B is affected by A at all? Also sizeof of that enum
> (if one gives it a name) is 8 with gcc-13. That is not allowed by the
> standard, IMO.

That is how C++ behaves for years and C2X mandates such behavior too.
Enumerators that don't fit into int were a GNU extensions (-pedantic-errors
rejects them) and for C have been handled weirdly in the past (only specific
enumerators that don't fit had wider types + the enum as whole).
enum E { A = 0xdeadbeefcafebabeULL, B = 2 };
int a = sizeof (enum E);
int b = sizeof (A);
int c = sizeof (B);
above yielded a = 8, b = 8, c = 4 in C, a = b = c = 8 in C++ and now in GCC 13
in C too.
See https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603809.html for more
details.

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jirislaby at gmail dot com]

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

--- Comment #7 from Jiri Slaby <jirislaby at gmail dot com> ---
(In reply to Jakub Jelinek from comment #6)
> That is how C++ behaves for years and C2X mandates such behavior too.
> Enumerators that don't fit into int were a GNU extensions (-pedantic-errors
> rejects them) and for C have been handled weirdly in the past (only specific
> enumerators that don't fit had wider types + the enum as whole).
> enum E { A = 0xdeadbeefcafebabeULL, B = 2 };
> int a = sizeof (enum E);
> int b = sizeof (A);
> int c = sizeof (B);
> above yielded a = 8, b = 8, c = 4 in C, a = b = c = 8 in C++ and now in GCC
> 13 in C too.

No problem having this in C2X. I'm not complaining about this feature. But
well, why does it happen in kernel's gnu11 (and in the example above too)? I
mean, I likely can fix the ata enum to be 1U << 31 (using BIT()) and alike so
that it all stays within uint. But how'd you propose to fix this:

(In reply to Martin Liška from comment #2)
> Note there's a similar issue I sent patch for:
> https://lore.kernel.org/all/f70c7a11-e81e-f6b9-a403-315117f4aa3a@suse.cz/

? I.e. how to %-format "B" in your example for both gcc-12 (c == 4) and gcc-13
(c == 8).

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jiri Slaby from comment #7)
> (In reply to Martin Liška from comment #2)
> > Note there's a similar issue I sent patch for:
> > https://lore.kernel.org/all/f70c7a11-e81e-f6b9-a403-315117f4aa3a@suse.cz/
> 
> ? I.e. how to %-format "B" in your example for both gcc-12 (c == 4) and
> gcc-13 (c == 8).

Just be consistent in the enumerator types within the same enum.
If you intend the whole enum to be int and its enumerators too,
use values that fit into int or cast the values explicitly to int.
So enum E { A = (int) 0xffffffff, B = -2 }; etc.
Or if you want the whole enum to have some other type (unsigned int, long,
unsigned long, long long, unsigned long long), use similar casts and/or
constant suffixes.
enum E { A = 0xffffffffU, B = -2U, C = (unsigned) 0xfffffffd } to get unsigned
int for everything, etc.

As written by Joseph in the commit log for PR36113 fix,
"This change was previously requested in PR 36113; it seems unlikely that
people are depending on the detail of the previous extension that some
enumerators had different types to others depending on whether their values
could be represented as int, and this patch makes the change to types of
enumerators unconditionally (if that causes problems in practice we could
always make it conditional on C2x mode instead)."
So, we have a proof that at least some projects (parts of Linux kernel) do rely
on this detail, now the big question is how often does this happen in the
kernel and if it affects anything else.  If it is widespread, as Joseph noted,
it could be restricted to C2X.  But you'll run into it when you switch to C2X
one day...

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jiri Slaby from comment #4)
> Another question is why B is affected by A at all? Also sizeof of that enum
> (if one gives it a name) is 8 with gcc-13. That is not allowed by the
> standard, IMO.

C99, C11, and C17 all say:

"The expression that defines the value of an enumeration constant shall be an
integer
constant expression that has a value representable as an int."

So enum { A = 0xffffffff } is a constraint violation and not allowed by the
standard anyway. Such code was always non-conforming and relying on an
(undocumented?) GCC extension, so the standard has nothing to say about the
type.

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jirislaby at gmail dot com]

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

--- Comment #10 from Jiri Slaby <jirislaby at gmail dot com> ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Jiri Slaby from comment #4)
> > Another question is why B is affected by A at all? Also sizeof of that enum
> > (if one gives it a name) is 8 with gcc-13. That is not allowed by the
> > standard, IMO.
> 
> C99, C11, and C17 all say:
> 
> "The expression that defines the value of an enumeration constant shall be
> an integer
> constant expression that has a value representable as an int."
> 
> So enum { A = 0xffffffff } is a constraint violation and not allowed by the
> standard anyway. Such code was always non-conforming and relying on an
> (undocumented?) GCC extension, so the standard has nothing to say about the
> type.

Ah, that's correct. So the question then is: is it a feature we can rely on
(even if undocumented -- can the behavior can be documented in gcc?), or we
should drop enum uses for values > MAX_INT?

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jirislaby at gmail dot com]

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

--- Comment #11 from Jiri Slaby <jirislaby at gmail dot com> ---
(In reply to Jiri Slaby from comment #10)
> Ah, that's correct. So the question then is: is it a feature we can rely on
> (even if undocumented -- can the behavior can be documented in gcc?), or we
> should drop enum uses for values > MAX_INT?

I think section 4.9 of gcc manual actually defines this:

The integer type compatible with each enumerated type (C90 6.5.2.2, C99 and C11
6.7.2.2).

  Normally, the type is unsigned int if there are no negative values in the
enumeration, otherwise int. 

So as long as all are unsigned, all is fine.

So it remains to define what happens when there is an u/long (the case above).

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|enums can be wrongly long   |[13 Regression] enum change
                   |in gcc-13 (in gnu99)        |causing Linux kernel to
                   |                            |fail to build due to Linux
                   |                            |depending on old behavior

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See bug 107314 comment #1 really.
The Linux sources will most likely should be fixed for this enum fix.

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
If the real issue in a particular place in the kernel is that a single 
(anonymous) enum type is being used for lots of different kinds of 
constants, then the appropriate fix in the kernel might be to split up the 
enum, so that large constants of one kind don't affect the types of small 
constants of a different kind.

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macro at orcam dot me.uk

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 107756 has been marked as a duplicate of this bug. ***

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[macro at orcam dot me.uk]

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

--- Comment #15 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
If in older C standard versions such enums are invalid, then I think
this should be a hard error rather than a silent ABI change for the code
produced.  Not all code out there will have sanity checks such as the
Linux kernel does and things will break for people in a tough way (think
a public header file defining an enumeration and objects linked that
define data of such an enumeration type and have been built with
different compiler versions).

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is a pedwarn (pedantic warning, with -pedantic-errors a hard error).

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[joseph at codesourcery dot com]

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

--- Comment #17 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 19 Nov 2022, macro at orcam dot me.uk via Gcc-bugs wrote:

> If in older C standard versions such enums are invalid, then I think
> this should be a hard error rather than a silent ABI change for the code
> produced.  Not all code out there will have sanity checks such as the

There is no ABI change.  The size of the enum type does not change.  What 
changes is the type given to enum constants in such an enum, if the value 
of the enum constant fits in int (now all enum constants in such an enum 
have the enum type rather than only those outside the range of int having 
the enum type).

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[macro at orcam dot me.uk]

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

--- Comment #18 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
Well, according to the assertion triggered `typeof (EM_MAX_SLOTS)' will
yield a data type of a different width depending on the compiler version.
Even if this GNU extension does not constitute a part of the ABI it does
guarantee link incompatibility for a feature we've had for decades now,
even if the old semantics was unintentional.  Data corruption cannot be
ruled out.  Besides, `sizeof (EM_MAX_SLOTS)' can also be used to build a
data type (an array type) and process it.

So I think a pedantic warning is not enough to fulfil the principle of
least surprise for the real world out there.  Therefore I maintain that
for pre-C2x compilations we either need to keep the old semantics,
possibly with a fat warning under `-Wall', or as I say make it a hard
error.

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[joseph at codesourcery dot com]

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

--- Comment #19 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 22 Nov 2022, macro at orcam dot me.uk via Gcc-bugs wrote:

> Well, according to the assertion triggered `typeof (EM_MAX_SLOTS)' will
> yield a data type of a different width depending on the compiler version.

I don't think typeof(expression) should really be considered part of the 
ABI.  Technically, yes, someone could declare a variable in a header as 
"extern typeof (EM_MAX_SLOTS) x;", and then the ABI for that variable 
would change.  What hasn't changed is the normal case - where the variable 
is declared as "extern enum whatever_the_tag_is x;" - the size of the enum 
type itself is the same as what it was before.

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis.machado at arm dot com

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 107917 has been marked as a duplicate of this bug. ***

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think this is WONTFIX on the GCC side?  Maybe changes.html or porting_to.html
should mention this issue.

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
We've not noticed other fallout in switching to GCC 13 for openSUSE, closing as
INVALID.  As far as I see the previous GCC "extension" was never documented.