https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Consumers need to interpret POINTER_PLUS_EXPR offset (and MEM_REF offset)
> as signed entity. This means you want to interpret the range as signed
> as well -- there is nothing wrong with the range as recorded as Andrew
> notices, it's fully correct.
My point is that the call to abort should be eliminated because it can never
take place. I don't know enough about the VRP pass and its users to tell if
it's because the consumer of get_range_info doesn't interpret it as signed or
for some other reason.
My other point (one somewhat related to bug 77898) is that it's confusing to
represent the VR_RANGE [-128, 127] of the signed char variable as a
VR_ANTI_RANGE ~[128, 18446744073709551487], or the entire offset as unsigned
size_type. I understand that it's not strictly incorrect but dealing with such
a range is more difficult, and more likely to lead bugs or missed optimization
opportunities such as the one in the test cases, than dealing with an ordinary
range.
