From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14137 invoked by alias); 2 Nov 2012 20:51:48 -0000 Received: (qmail 14087 invoked by uid 48); 2 Nov 2012 20:51:32 -0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/55079] [4.8 regression] false positive -Warray-bounds Date: Fri, 02 Nov 2012 20:51: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: hubicka at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: 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-11/txt/msg00182.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079 --- Comment #7 from Jan Hubicka 2012-11-02 20:51:31 UTC --- Actually not, what happen here is that we unroll the loop 17 times based on the fact that the array access iterates from taillen to tailen+n_iterations and the array size is 17. Later in compilation we prove that tailen is actually non-zero by VRP and we work the hard way across the unrolled loop body to work out that the last access must be out of bounds. So this is not bug of unroller to not remove statement. Short of teaching SCEV about the value range of initial tailen, we really can't reduce number of iterations. We discussed it here http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01103.html I do not think we really can solve these cases reliably short of silencing the warning on unrolled loop copies and other duplicated statements.