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

[Bug c++/67047] New: 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

            Bug ID: 67047
           Summary: GCC accepts ill-formed program with enumerator not
                    representable in uintmax_t
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Consider the following program (prog.cc):

#include <cstdint>
#include <limits>
enum { x = std::numeric_limits<std::uintmax_t>::max(), y };
int main() {}

Compile it with the following command line:

g++ prog.cc -std=c++14 -pedantic-errors

No error messages are given. The program is ill-formed by the last sentence of
the third list item of [dcl.enum]p5 (http://eel.is/c++draft/dcl.enum#5) so at
least one error message was expected.

I have tried this with gcc HEAD 6.0.0 20150728 here:

http://melpon.org/wandbox/permlink/8EVR4wM7TqLBTrVG

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[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), "");

[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 #3 from Anders Granlund <anders.granlund.0 at gmail dot com> ---
It seems like the increment of the enumerator x triggered the use of the
following compiler extension:

https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html

This without any error messages. That is not ok! Remember that we used
-pedantic-errors.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-29
     Ever confirmed|0                           |1

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes you can verify that with

static_assert( std::is_same<std::underlying_type<decltype(x)>::type, unsigned
__int128>::value, "");

I suppose there should be a diagnostic with -Wpedantic (Clang has a
-Wenum-too-large warning).

[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 #5 from Anders Granlund <anders.granlund.0 at gmail dot com> ---
(In reply to Jonathan Wakely from comment #4)
> Yes you can verify that with
> 
> static_assert( std::is_same<std::underlying_type<decltype(x)>::type,
> unsigned __int128>::value, "");
> 
> I suppose there should be a diagnostic with -Wpedantic (Clang has a
> -Wenum-too-large warning).

Nice use of type traits there for the confirmation. Yes, a -Wpedantic warning
is what we want here.

I haven't tried this with the c compiler (the online compiler i'm using does
not support c mode), but this bug may exists there also.