From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91927 invoked by alias); 11 Sep 2015 16:13:54 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 91879 invoked by uid 48); 11 Sep 2015 16:13:51 -0000 From: "pangbw at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds" Date: Fri, 11 Sep 2015 16:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.8.3 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: pangbw at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-09/txt/msg00976.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59124 --- Comment #21 from baoshan --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez 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. >=20 > 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 t= hat > line in test.c.079t.vrp1.=20 >=20 > ;; 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 =3D i_2 + 4294967290; > [test.c:9:10] # RANGE [4294967291, 4294967295] NONZERO 4294967295 > _52 =3D (long unsigned intD.10) _51; > [test.c:9:10] # RANGE [17179869164, 17179869180] NONZERO 17179869180 > _53 =3D _52 * 4; > [test.c:9:10] # PT =3D nonlocal > _54 =3D bar_12(D) + _53; > [test.c:9:23] # VUSE <.MEM_48> > _55 =3D [test.c:9:23] bazD.1755[_51]; > [test.c:9:18] # .MEM_56 =3D VDEF <.MEM_48> > [test.c:9:10] *_54 =3D _55; > [test.c:9:13] # RANGE [4294967290, 4294967294] > _59 =3D i_2 + 4294967289; > [test.c:9:10] # RANGE [4294967290, 4294967294] NONZERO 4294967295 > _60 =3D (long unsigned intD.10) _59; > [test.c:9:10] # RANGE [17179869160, 17179869176] NONZERO 17179869180 > _61 =3D _60 * 4; > [test.c:9:10] # PT =3D nonlocal > _62 =3D bar_12(D) + _61; > [test.c:9:23] # VUSE <.MEM_56> > _63 =3D [test.c:9:23] bazD.1755[_59]; > [test.c:9:18] # .MEM_64 =3D VDEF <.MEM_56> > [test.c:9:10] *_62 =3D _63; > ;; succ: 11 [100.0%] (FALLTHRU,EXECUTABLE) >=20 > 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 va= lue 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=67548 --- Comment #3 from H.J. Lu --- 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".