https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(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?
Ranger is coming back with:
_28 : [irange] int [+INF, +INF] NONZERO 0x7ffffffe
which sounds reasonable, and the reason you're seeing 2147483647.
