https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102879
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Aldy Hernandez from comment #1) > > > So, presumably _62 == 0 cannot be true. If _62 == 0, then > > 0 = _30 >> _6; > > But that cannot happen because _30 is 2 if you follow the series of copies > from the "c" global. > > There is no way 0 = 2 >> x can ever be true. > > There's probably a couple things missing here. Maybe > operator_rshift::op1_range needs to be taught that ~[0,0] = x >> y implies x > is non-zero. But also, we can't see through the load from the c=2 global. > Shouldn't that c=2 have been propagated by someone at this point? (VRP1?) well, that depends on _6. 0 = _30 >> 32 is always true. now, we do happen to know that _6 is [0,1], so if we did manage to determine that _30 is [2,2], then the we will fold [2,2] >> [0,1] into [1,2] and then everything should fall into place as we know we can never take that breanch. That means our core issue is c.2_28 = c; _29 = (char) c.2_28; _30 = (int) _29; if (_29 >= 0) that we don't propagate the 2 into the c.2_28. we are limited to a range of [1,127] because of that.
