Handle anti-ranges of MIN,MAX uniformly.
authorAldy Hernandez <aldyh@redhat.com>
Mon, 26 Apr 2021 17:24:09 +0000 (19:24 +0200)
committerAldy Hernandez <aldyh@redhat.com>
Mon, 26 Apr 2021 20:28:04 +0000 (22:28 +0200)
commite6455a099ec74071ba9c011cc314a48cadbe2bfe
tree00f54135bd65305be20f774b7d0a0f5714e1a8c4
parent2e0b1c6ce3afe0670b96444c6b955ce184ed0046
Handle anti-ranges of MIN,MAX uniformly.

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.

gcc/ChangeLog:

* value-range.cc (irange::irange_set_1bit_anti_range): Add assert.
(irange::set): Call irange_set_1bit_anti_range for handling all
1-bit ranges.  Fall through on ~[MIN,MAX].
gcc/value-range.cc