> I think excluding enums had sth to do with C++ -f[no-]strict-enums
> (whatever is the default). Just tried to figure where the check
> came from ... both calls are keyed on INTEGER_TYPE...
Here's the relevant block of code from the C++ front-end:
/* The middle-end currently assumes that types with TYPE_PRECISION
narrower than their underlying type are suitably zero or sign
extended to fill their mode. Similarly, it assumes that the front
end assures that a value of a particular type must be within
TYPE_MIN_VALUE and TYPE_MAX_VALUE.
We used to set these fields based on bmin and bmax, but that led
to invalid assumptions like optimizing away bounds checking. So
now we just set the TYPE_PRECISION, TYPE_MIN_VALUE, and
TYPE_MAX_VALUE to the values for the mode above and only restrict
the ENUM_UNDERLYING_TYPE for the benefit of diagnostics. */
ENUM_UNDERLYING_TYPE (enumtype)
= build_distinct_type_copy (underlying_type);
TYPE_PRECISION (ENUM_UNDERLYING_TYPE (enumtype)) = precision;
set_min_and_max_values_for_integral_type
(ENUM_UNDERLYING_TYPE (enumtype), precision, sgn);
/* If -fstrict-enums, still constrain TYPE_MIN/MAX_VALUE. */
if (flag_strict_enums)
set_min_and_max_values_for_integral_type (enumtype, precision, sgn);
So the compiler should still not optimize if -fno-strict-enums AFAICS.
--
Eric Botcazou
