[Bug c++/67047] GCC accepts ill-formed program with enumerator not representable in uintmax_t

[anders.granlund.0 at gmail dot com]

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

--- Comment #2 from Anders Granlund <anders.granlund.0 at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> So the enum is an unsigned type so UINTMAX_MAX +1 is 0 as it is always
> representable due to the rules of unsigned types and wrapping.  Unless I
> miss-understand how this is supposed to work and the wrapping rules for
> unsigned types don't come into play.

Incrementing enumerators never cause wrapping according to the c++ standard.
This follows from this part of [dcl.enum]p5
(http://eel.is/c++draft/dcl.enum#5):

"Otherwise the type of the enumerator is the same as that of the preceding
enumerator unless the incremented value is not representable in that type, in
which case the type is an unspecified integral type sufficient to contain the
incremented value. If no such type exists, the program is ill-formed."

If you test with static_assert(y != 0, ""); you can also see that no wrapping
has been done.

The real cause of the bug can be seen by observing that the following static
assert succeeds:

static_assert(sizeof (y) > sizeof(std::uintmax_t), "");