From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4943 invoked by alias); 7 Dec 2012 12:55:07 -0000 Received: (qmail 4808 invoked by uid 48); 7 Dec 2012 12:54:37 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds (also seen at -O3 bootstrap) Date: Fri, 07 Dec 2012 12:55: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-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Priority Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2012-12/txt/msg00700.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 --- Comment #10 from Richard Biener 2012-12-07 12:54:35 UTC --- I expect this to be a major nuisance on our users for 4.8. And I don't see a good way to solve this issue! For the testcase in comment#8 we warn during early VRP but not from late VRP. OTOH I'd rather disable the second VRPs array bound warnings ... What would be interesting to see is if there is a way for VRP to prove (after the unrolling happened) that the access is dead. For the testcase in comment#8 something magic happens for a[3] (no warning) vs. a[4] (warning). Maybe we should refrain from doing the speculative new complete unrolling during cunrolli? OTOH what happens in VRP for int a[4] case is that it estimates the number of iterations of the outer (not unrolled) loop to be 4, one too large: Analyzing # of iterations of loop 1 exit condition [0, + , 1] < n_8 bounds on difference of bases: 0 ... 4294967295 result: # of iterations n_8, bounded by 4294967295 Statement (exit)if (i_2 < n_8) is executed at most n_8 (bounded by 4294967295) + 1 times in loop 1. here # of iteration analysis does not take into account that n_8 is [0, 3] already. Of course there is no good way to feed it this information (we are currently iterating and not conservative!) without re-computing number of iterations and SCEV all the time (that was shot down to be very much too time consuming).