[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #20 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to baoshan from comment #19)
> We can see the value of up_sub is represented as unsigned int value
> 4294967291 which is really weird to me, it suppose to be a int value -5 here.

All counters are unsigned. You can see what code looks like to GCC at exactly
that moment by using -fdump-tree-all-all-lineno and looking for that line in
test.c.079t.vrp1. 

;;   basic block 10, loop depth 1, count 0, freq 1430, maybe hot
;;   Invalid sum of incoming frequencies 1226, should be 1430
;;    prev block 9, next block 11, flags: (NEW, REACHABLE)
;;    pred:       9 [85.7%]  (TRUE_VALUE,EXECUTABLE)
;;   starting at line 9
  [test.c:9:13] # RANGE [4294967291, 4294967295]
  _51 = i_2 + 4294967290;
  [test.c:9:10] # RANGE [4294967291, 4294967295] NONZERO 4294967295
  _52 = (long unsigned intD.10) _51;
  [test.c:9:10] # RANGE [17179869164, 17179869180] NONZERO 17179869180
  _53 = _52 * 4;
  [test.c:9:10] # PT = nonlocal
  _54 = bar_12(D) + _53;
  [test.c:9:23] # VUSE <.MEM_48>
  _55 = [test.c:9:23] bazD.1755[_51];
  [test.c:9:18] # .MEM_56 = VDEF <.MEM_48>
  [test.c:9:10] *_54 = _55;
  [test.c:9:13] # RANGE [4294967290, 4294967294]
  _59 = i_2 + 4294967289;
  [test.c:9:10] # RANGE [4294967290, 4294967294] NONZERO 4294967295
  _60 = (long unsigned intD.10) _59;
  [test.c:9:10] # RANGE [17179869160, 17179869176] NONZERO 17179869180
  _61 = _60 * 4;
  [test.c:9:10] # PT = nonlocal
  _62 = bar_12(D) + _61;
  [test.c:9:23] # VUSE <.MEM_56>
  _63 = [test.c:9:23] bazD.1755[_59];
  [test.c:9:18] # .MEM_64 = VDEF <.MEM_56>
  [test.c:9:10] *_62 = _63;
;;    succ:       11 [100.0%]  (FALLTHRU,EXECUTABLE)

It seems GCC at some moment unrolls the loop and creates such block with those
ranges. Probably, the block is unreachable, but it would be better to not
create it in the first place. Finding out where and why it is created would
help to figure out a fix.