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-315117f4a...@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...
