[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898

--- Comment #9 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #8)
> I agree that in many cases there isn't enough information to tell that a
> range is final and can't be further improved.  But there certainly are such
> cases (the test case in comment #0 is an example of one)

The function could get inlined and i become constant...

> I think it should be possible to call set_range_info() on the result of the
> __builtin_object_size, and perhaps even on the offset variable in (p += i)
> since its value is constrained not only by the range of its type (before
> VRP1) and by statements like the 'if (i < 0 || 1 < i) i = 0;' (after VRP1)
> but also by the increment '(p += i)' which is only defined for i in [0, 3]
> as determined by the tree-object-size pass before VRP1.  Let me give that a
> try.

Careful with that last point. When we compute i+10 (in type int), we do not
restrict the range of i to [INT_MIN, INT_MAX-10]. The reason is that this
restriction is only valid starting from this statement, not from the definition
of i.

> It seems to me that there should many other opportunities to call
> set_range_info() in GCC that could help improve the generated code (and the
> ability to find bugs via warnings).  I count just 9 calls to the function in
> the whole code base.

It makes sense that most range computation happens in VRP (which has a single
set_range_info in a loop at the end). This pass duplicates variables to get
some sort of "local" range, which allows for tighter estimates. If you replace
'i = 0' with 'return' in your first example, then i may generally be any int,
but in the branch that contains __bos, it can only be in the range [0, 1],
which is something you are only aware of during the VRP pass.