On 4/26/21 3:57 PM, Aldy Hernandez wrote:
The -fstrict-enums comment in the VR_ANTI_RANGE handling code is out
of date, as out-of-range ranges have already been handled by this
time. I've removed it.
Furthermore, optimizing ~[MIN,MAX] as VARYING instead of UNDEFINED is
an old idiom. I've been wanting to change it for a while, but have
only remembered late in the release cycle when it was too risky.
What I've chosen to do in this case is fall through to the code that
normalizes the range. This will correctly turn ~[MIN,MAX] into
UNDEFINED, yet leaving things alone in the case of -fstrict-enums
where [MIN,MAX] may not necessarily include the entire range of the
underlying precision. For example, if the domain of a strict enum is
[3,5] setting a VR_ANTI_RANGE of ~[3,5] should not cause neither
VR_UNDEFINED nor VR_VARYING, but just plain ~[3,5].
This is similar to what we do for -fstrict-enums when we set a range
of [3,5]. We leave it as a VR_RANGE, instead of upgrading it to
VR_VARYING.
Oh...I think it's time we started handling 1-bit anti-ranges uniformly,
hence the change to call irange_set_1bit_anti_range for both legacy and
multi-range.
Tested on x86-64 Linux.
OK?
OK. -fstrict-enum and 1 bit signed is such a pain :-P as long as we
are consistent and correct :-)
Andrew
