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

["pangbw at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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?
>From gcc-bugs-return-496999-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 11 16:40:00 2015
Return-Path: <gcc-bugs-return-496999-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 109298 invoked by alias); 11 Sep 2015 16:40:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 108937 invoked by uid 48); 11 Sep 2015 16:39:56 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"
Date: Fri, 11 Sep 2015 16:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67548-4-zTn6NujzED@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67548-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67548-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-09/txt/msg00977.txt.bz2
Content-length: 1410

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg548

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
We have

enum ld_plugin_symbol_resolution
{
  LDPR_UNKNOWN = 0,

  /* Symbol is still undefined at this point.  */
  LDPR_UNDEF,

  /* This is the prevailing definition of the symbol, with references from
     regular object code.  */
  LDPR_PREVAILING_DEF,

  /* This is the prevailing definition of the symbol, with no
     references from regular objects.  It is only referenced from IR
     code.  */
  LDPR_PREVAILING_DEF_IRONLY,

  /* This definition was pre-empted by a definition in a regular
     object file.  */
  LDPR_PREEMPTED_REG,

  /* This definition was pre-empted by a definition in another IR file.  */
  LDPR_PREEMPTED_IR,

  /* This symbol was resolved by a definition in another IR file.  */
  LDPR_RESOLVED_IR,

  /* This symbol was resolved by a definition in a regular object
     linked into the main executable.  */
  LDPR_RESOLVED_EXEC,

  /* This symbol was resolved by a definition in a shared object.  */
  LDPR_RESOLVED_DYN,

  /* This is the prevailing definition of the symbol, with no
     references from regular objects.  It is only referenced from IR
     code, but the symbol is exported and may be referenced from
     a dynamic object (not seen at link time).  */
  LDPR_PREVAILING_DEF_IRONLY_EXP
};

None of them is applicable to a weakdef with "ld -r".