https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61584
Bug ID: 61584
Summary: What defines std::underlying_type?
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
This is not a library bug because std::underlying_type simply wraps the
__underlying_type() intrinsic.
enum x {};
static_assert( std::is_same< std::underlying_type< x >::type, int >::value,
"enum does not default to int." );
The x64 ABI, Figure 3.1, suggests that enumeration types are usually considered
identical to [signed] int, except
"C++ and some implementations of C permit enums larger than an int. The
underlying type is bumped to an unsigned int, long int or unsigned long int, in
that order."
This is the only mention of "underlying type" in the ABI, and the Itanium C++
gABI has nothing to add. However, common sense dictates the same rule because
unscoped, unfixed enumerations promote to the integer type of least rank that
can represent any enumerator. The underlying type of such an enumeration does
*not* affect its conversions, and can only be observed by underlying_type
introspection. (A std-discussion request to require promotion to match
underlying_type spurred this report.)
By the most relevant available specification, int should be the default
underlying type for unscoped, unfixed enumerations. Scoped, unfixed
enumerations might follow suit, according to the spirit of the ABI, but there's
more wiggle room because they do not implicitly convert to the underlying type.
(However, users are likely to use underlying_type for explicit conversions, so
the same issues arise.)
