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

["jirislaby at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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).