https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #5 from Jeffrey A. Law <law at redhat dot com> --- This (and pr80641) all feel closely related. Transforming into a trap early means we're not likely to get these reports which would be unfortunate because they often point to a failing of the optimizer. I think we should start by figuring out why VRP didn't help us here. From looking at the stuff we've got so far, I'd focus on: ;; basic block 13, loop depth 1, count 357916946 (estimated locally), maybe hot ;; prev block 12, next block 14, flags: (NEW, REACHABLE, VISITED) ;; pred: 3 [50.0% (guessed)] count:357916948 (estimated locally) (FALSE_VALUE,EXECUTABLE) _117 = ASSERT_EXPR <_17, _17 > 2>; _1 = _117 + 18446744073709551614; if (_1 > _117) goto <bb 14>; [33.00%] else goto <bb 28>; [67.00%] ;; basic block 14, loop depth 1, count 59056296 (estimated locally), maybe hot ;; Invalid sum of incoming counts 118112592 (estimated locally), should be 59056296 (estimated locally) ;; prev block 13, next block 15, flags: (NEW, REACHABLE, VISITED) ;; pred: 13 [33.0% (guessed)] count:118112592 (estimated locally) (TRUE_VALUE,EXECUTABLE) _185 = ASSERT_EXPR <_1, _1 > _117>; _184 = ASSERT_EXPR <_185, _185 > 18446744073709551613>; _152 = ASSERT_EXPR <_117, _117 < _184>; _40 = ASSERT_EXPR <_152, _152 <= 1>; _83 = a$16_134 - a$8_73; _84 = _83 /[ex] 4; _85 = (long unsigned int) _84; if (_85 > 18446744073709551613) goto <bb 15>; [67.00%] else goto <bb 16>; [33.00%] ;; succ: 15 [67.0% (guessed)] count:39567718 (estimated locally) (TRUE_VALUE,EXECUTABLE) ;; 16 [33.0% (guessed)] count:19488578 (estimated locally) (FALSE_VALUE,EXECUTABLE) The biggest problem I see is we don't know the relationship between a$16_134 and a$8_73 in BB14. In fact we know nothing about a$16_134 at that point. So I don't see any way to simplify the conditional at the end of BB14. The conditional at the end of BB12 is an overflow check. But we're dealing with unsigned types, so we can't rule out overflow. But even knowing what direction it took doesn't help us. So we can't simplify/eliminate it nor use its direction to help. Note this differs from 79095 because in 79095 we had information about the relationship between the two key pointers -- namely we knew they were not the same. That allowed us to determine their difference was nonzero and the result of the exact division had to be nonzero as well. All that played into being able to eventually prove the path leading to the problem memset was not executable. I don't see anything in this BZ that would allow us to make the same determination here.