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

[pangbw at gmail dot com]

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

--- Comment #21 from baoshan <pangbw at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #20)
> (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.

Don't you think the range value is strange? how it is possible the range value
is so big according the code?