https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > VRP2/DOM3 produces the wrong folding for some reason:
> > Folding statement: _27 = b.6_9 * 2;
> > Queued stmt for removal. Folds to: 2147483647
> >
> > I don't uinderstand how it could get that from:
>
> Putting a breakpoint in execute_ranger_vrp() for the VRP2 instance, and
> dumping what the ranger knows with debug_ranger() we see:
>
> =========== BB 3 ============
> b.6_9 [irange] int [1334323000, +INF] NONZERO 0x7fffffff
> <bb 3> [local count: 357878153]:
> _28 = b.6_9 * 2;
> ivtmp.19_27 = 2147483647;
> ivtmp.22_31 = (unsigned long) &f;
> goto <bb 5>; [100.00%]
>
> ivtmp.19_27 : [irange] unsigned int [2147483647, 2147483647] NONZERO
> 0x7fffffff
> _28 : [irange] int [+INF, +INF] NONZERO 0x7ffffffe
> ivtmp.22_31 : [irange] unsigned long [1, +INF]
>
> So on entry to BB3, b.6_9 is [1334323000, +INF]. This comes from the 2->3
> edge, which is the only incoming edge to BB3.
>
> Isn't multiplying any number in that range an overflow, and thus undefined?
ok, that part makes sense but how did that b.6_9 get that range in the first
place? Because it does not even makes sense.
That is these exports:
2->3 (T) c.5_7 : [irange] int [1334323000, +INF] NONZERO 0x7fffffff
2->3 (T) _8 : [irange] long unsigned int [1334323000, 2147483647] NONZERO
0x7fffffff
2->3 (T) b.6_9 : [irange] int [1334323000, +INF] NONZERO 0x7fffffff
2->3 (T) _10 : [irange] long unsigned int [1334323000, 2147483647]
NONZERO 0x7fffffff
2->3 (T) _11 : [irange] long unsigned int [3481806647, 3481806649]
NONZERO 0xcf88273f
2->3 (T) _12 : [irange] long unsigned int [0, 2] NONZERO 0x3
seems wrong.
We originally had (c and d cause a memory read):
c.5_7 = c;
_8 = (long unsigned int) c.5_7;
b.6_9 = b;
_10 = (long unsigned int) b.6_9;
_11 = _8 + _10;
_12 = _11 + 18446744070227744969;
if (_12 <= 2)
so _11 export seems correct but _8 and _10 added together needs to be make _11.
Since it is unsigned, the whole range for both numbers can make _11's range;
that is we can't say anything about _8 or _10. Even if _11 is signed, I don't
see how _8 and _10 could be described at all ... since _8 could be 0 and _10
could be 3481806647 and the range that is exported for _8 does not even include
0.
Unless I am missing something obvious here.
