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.