From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112163 invoked by alias); 18 Sep 2015 18:32:16 -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 112106 invoked by uid 48); 18 Sep 2015 18:32:12 -0000 From: "manu at gcc dot gnu.org" 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, 18 Sep 2015 18:32: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: manu at gcc dot gnu.org 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/msg01511.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59124 --- Comment #28 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to baoshan from comment #27) > > 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 bette= r to > > not create it in the first place. Finding out where and why it is creat= ed > > would help to figure out a fix. >=20 >=20 > At pass "cunrolli", it would unroll the loops according the estimated > iterate times. The problem is at this time it use array > ref(infer_loop_bounds_from_ref) to infer the iterate times which is not > accurate. The inaccurate iterate times result the extra blocks. The question is why is it inaccurate? Note that cunrolli says: Statement _14 =3D baz[_9]; is executed at most 5 (bounded by 5) + 1 times in loop 2. Loop 2 iterates at most 6 times. Analyzing # of iterations of loop 2 exit condition [i_2 + 4294967295, + , 4294967295] !=3D 0 bounds on difference of bases: -4294967295 ... 0 Applying pattern match.pd:71, generic-match.c:9500 result: # of iterations i_2 + 4294967295, bounded by 4294967295 Estimating sizes for loop 2 BB: 7, after_exit: 0 size: 2 if (j_3 !=3D 0) Exit condition will be eliminated in last copy. BB: 6, after_exit: 1 size: 1 _9 =3D j_3 + 4294967295; size: 0 _10 =3D (long unsigned int) _9; Applying pattern match.pd:71, generic-match.c:9500 Applying pattern match.pd:136, generic-match.c:6019 size: 1 _11 =3D _10 * 4; Applying pattern match.pd:71, generic-match.c:9500 Applying pattern match.pd:136, generic-match.c:6019 size: 1 _13 =3D bar_12(D) + _11; size: 1 _14 =3D baz[_9]; size: 1 *_13 =3D _14; size: 7-0, last_iteration: 2-2 Loop size: 7 Estimated size after unrolling: 28 pr59124.c:8:5: note: loop turned into non-loop; it never loops. pr59124.c:8:5: note: loop with 7 iterations completely unrolled Last iteration exit edge was proved true. Forced statement unreachable: _14 =3D baz[_9]; However, it is clear that _14 =3D baz[_9] is executed only 5 times (not 5 t= imes + 1). Why is this estimate wrong? >>From gcc-bugs-return-497534-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 18 18:53:24 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 11657 invoked by alias); 18 Sep 2015 18:53:24 -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 9437 invoked by uid 48); 18 Sep 2015 18:53:20 -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, 18 Sep 2015 18:53: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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-09/txt/msg01512.txt.bz2 Content-length: 378 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #29 from baoshan --- > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5 > times + 1). Why is this estimate wrong? The max value of n is 6, so the max value of i is 5 as "i < n", then the max value of j is 4 as "j = i - 1" which means the max iterate times is 4.