Normalize VARYING for -fstrict-enums.
The problem here is that the representation for VARYING in
-fstrict-enums is different between value_range and irange.
The helper function irange::normalize_min_max() will normalize to
VARYING only if setting the range to the entire domain of the
underlying type. That is, [0, 0xff..ff], not the domain as defined by
-fstrict-enums. This causes problems because the multi-range version
of varying_p() will return true if the range is the domain as defined
by -fstrict-enums. Thus, normalize_min_max and varying_p have
different concepts of varying for multi-ranges.
(BTW, legacy ranges are different because they never look at the
extremes of a range to determine varying-ness. They only look at the
kind field.)
One approach is to change all the code to limit ranges to the domain
in the -fstrict-enums world, but this won't work because there are
various instances of gimple where the values assigned or compared are
beyond the limits of TYPE_{MIN,MAX}_VALUE. One example is the
addition of 0xffffffff to represent subtraction.
This patch fixes multi-range varying_p() and set_varying() to agree
with the normalization code, using the extremes of the underlying type,
to represent varying.
gcc/ChangeLog:
PR tree-optimization/97767
* value-range.cc (dump_bound_with_infinite_markers): Use
wi::min_value and wi::max_value.
(range_tests_strict_enum): New.
(range_tests): Call range_tests_strict_enum.
* value-range.h (irange::varying_p): Use wi::min_value
and wi::max_value.
(irange::set_varying): Same.
(irange::normalize_min_max): Remove comment.
gcc/testsuite/ChangeLog:
* g++.dg/opt/pr97767.C: New test.