https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91789
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
The ranger isn't really about forwards vs backwards, its about an approach in
which the basics are understood without special casing, and when applied
properly, direction won't matter... eliminating this sort of ordering issue.
This is another example which we intend to just always "get", but requires
multiple components to work together:
It requires 2 different things.
1) ranges to know that after the second conditional a = [0, MAX]
2) relationals such that the property b >= a is known after the first
conditional.
- For strictly ranges, the final conditional produces b = [MIN, -1] on the TRUE
edge.
- If the known relations are queried, and the known relation b >= a is applied
to a = [0, MAX], rangeops calculates b >= [0, MAX] and we get a range of [0,
MAX] for b
Since both must be true simultaneously, the results [MIN, -1] and [0, MAX] will
be intersected and produces an empty range on the TRUE edge, which in ranger
world means the range is impossible. Thus we know the edge is not executable
and can be removed.
This range evaluation code is present in the ranger now and resolves the range
parts, but wont make trunk this release.
The relational code is being developed for next stage 1, so does not exist yet.
It is required to replace VRP and the symbolic representation currently used by
value_range for equivalences and relations. This will be my focus over the next
few months.
I would anticipate this being fixed in the next release when the ranger goes
live. I will add this test to my testsuite to ensure it works as expected.
