From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-414872-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 25930 invoked by alias); 11 Feb 2013 09:33:01 -0000
Received: (qmail 25757 invoked by uid 48); 11 Feb 2013 09:32:32 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning
Date: Mon, 11 Feb 2013 09:33: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: diagnostic, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56273-4-4ztF0BZkEv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56273-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56273-4@http.gcc.gnu.org/bugzilla/>
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: <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
X-SW-Source: 2013-02/txt/msg01037.txt.bz2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-11 09:32:31 UTC ---
(In reply to comment #2)
> The problem is a missing VRP.  Basically ivopts changes:
>   if (j_10 != 9)
> 
> Which works into:
> 
>   j_10 = ivtmp.12_56;
>   if (ivtmp.12_56 != 9)
>     goto <bb 7>;
>   else
>     goto <bb 6>;
> 
> 
> Which does not work as VRP cannot figure out j_10 will never be 9.
> I have some patches to VRP which improves this but I don't remember if it fixes
> this case where there is an assignment which is used later on.

A similar case was PR55079 which was

   j_10 = ivtmp.12_56 + 1;
   if (ivtmp.12_56 == 5)
     ...

I handled already.  Extending this to copies should be easy.  If I do that
it still doesn't work.

That's because we warn for stuff[j_15] and j_15 is [9, 16] (we completely
peel the loop).  The access is guarded with

  <bb 30>:
  j_55 = ivtmp.12_56 + 8;
  j_72 = ivtmp.12_56 + 8;
  if (j_72 != 9)
    goto <bb 31>;
  else
    goto <bb 3>;

  <bb 31>:
  # j_15 = PHI <j_55(30)>
  _12 = stuff[j_15].a;
  if (_12 != 0)

but j_72 is [9, 16] as well and ivtmp.12_56: [1, 9].  Improving VRP to
see that j_55 is != 9 in bb31 will only lead to [10, 16] which is also
out-of-bounds.

It might very well be that folding the < test to != in VRP1 causes most
of the issues.  Indeed -fdisable-tree-vrp1 "fixes" the testcase.  We
should probably delay that optimization to VRP2 only, thus don't do

Folding statement: if (i_1 <= 8)
Simplified relational if (i_1 <= 8)
 into if (i_1 != 9)

(simplify_cond_using_ranges).