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.

Reply via email to