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.)