[Bug c++/61568] New: unscoped enums different types differ from __underlying_type

[Bug c++/61568] New: unscoped enums different types differ from __underlying_type

[myriachan at cox dot net]

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

            Bug ID: 61568
           Summary: unscoped enums different types differ from
                    __underlying_type
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: myriachan at cox dot net

If you have an unscoped, unfixed-type enum whose members exist solely within
[0...INT_MAX], the enum type is considered "signed int", but the
"__underlying_type" intrinsic operator returns "unsigned int".  As a result,
the following paradoxical C++ code compiles when it should not.  (This also
occurs if you use type_traits and std::underlying type instead of the intrinsic
directly.)

This may be a duplicate of bug 58559.


template <typename T> struct type_is_unsigned_int { static const bool value =
false; };
template <> struct type_is_unsigned_int<unsigned int> { static const bool value
= true; };

enum unscoped_unfixed_size_enum {
        some_enum_name = 0,
};

static_assert(
        static_cast<unscoped_unfixed_size_enum>(-1) <
                static_cast<unscoped_unfixed_size_enum>(0),
        "This assert doesn't fire, indicating that the enum is signed.");
static_assert(
        static_cast<__underlying_type(unscoped_unfixed_size_enum)>(-1) >
                static_cast<__underlying_type(unscoped_unfixed_size_enum)>(0),
        "But neither does this one!  It's inconsistent.");
static_assert(
       
type_is_unsigned_int<__underlying_type(unscoped_unfixed_size_enum)>::value,
        "The exact type in the implementation is, in fact, \"unsigned int\".");

[Bug c++/61568] unscoped enums different types differ from __underlying_type

[harald at gigawatt dot nl]

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

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #1 from Harald van Dijk <harald at gigawatt dot nl> ---
The C++ standard requires an unscoped enumeration type with an underlying type
that is not fixed to promote to signed int, if signed int is capable of
representing all the values in the enumeration's range. And the enumeration's
range depends on the values of the enumeration constants, not on the
enumeration's underlying type, so it requires this even if the underlying type
is unsigned int. This may be confusing, but I think that what GCC implements is
exactly what the standard requires, and that there is no bug in GCC here.

This may indeed be a duplicate of bug 58559, which seems to be invalid for the
same reason. In the comparison e < 0, e is promoted to signed int (except in C,
where it does promote to unsigned int). In the cast (long long) e, the
enumeration value (with an unsigned underlying type) is converted directly to
long long, without any intermediate promotion.

[Bug c++/61568] unscoped enums different types differ from __underlying_type

[myriachan at cox dot net]

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

--- Comment #2 from Melissa <myriachan at cox dot net> ---
(In reply to Harald van Dijk from comment #1)
> The C++ standard requires an unscoped enumeration type with an underlying
> type that is not fixed to promote to signed int, if signed int is capable of
> representing all the values in the enumeration's range. And the
> enumeration's range depends on the values of the enumeration constants, not
> on the enumeration's underlying type, so it requires this even if the
> underlying type is unsigned int. This may be confusing, but I think that
> what GCC implements is exactly what the standard requires, and that there is
> no bug in GCC here.

I think you're right about this, Harold, particularly because clang exhibits
the same behavior.  (Visual Studio 2012 and 2013 don't, but they use an
underlying type of "signed int"; this makes MSVS equally compliant under this
interpretation of the Standard but for a different reason.)

But I also think that the Standard is being a little silly here.  It seems
broken to me that an enum promotes differently than its underlying type does. 
Maybe that compilers are permitted to do this should be reported as a possible
erratum in the Standard.