From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 10E50382E443; Wed,  7 Dec 2022 17:12:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 10E50382E443
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1670433171;
	bh=pbbIaArCC5R6JmgpnjEA9aGdXLedwrdqwqepOFgPLpg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=NK0eHNDpLu+0jcuUr9Xg7e4j4u4Er2t9G4jPTcHRnGBZK+jjwndioCbIANV8b7Hvf
	 cwyPAkkqFYRLLzM4eRbLx8fwJadMzXttTDIEOfTvnKpG1lncN/SUW72Dm12KUS8XGJ
	 rxE+Lv59It0zRMl/Kmzj6rXEoFhKTzdvwboKksbM=
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107986] [12/13 Regression] Bogus
 -Warray-bounds diagnostic with std::sort
Date: Wed, 07 Dec 2022 17:12:49 +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: 12.2.0
X-Bugzilla-Keywords: diagnostic, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat 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: 12.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107986-4-laRHStd4pH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107986-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107986-4@http.gcc.gnu.org/bugzilla/>
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
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107986

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #3)
> Note the old VRP was able to at least tell that qa was [0, +INF] by means=
 of
> iterating and saturating to +INF after too many iterations.  SCEV isn't of
> help here.  Since we've lost the last lattice-based (iterating) VRP pass =
now
> what's the plan for cases like this?



When we first process a statement we set the LHS to varying first. Then we
resolve all the inputs, and then do the final calculation of the LHS and sa=
ve
that.=20

This is done to prevent resolving inputs along back edges from entering a
cycle. If the back edge ever returns to this def, it will pick up the saved
varying value and stop looking..

This is conservatively correct, but it does mean in the case of PHI nodes, =
we
are not optimistic about the outcome if there is a cyclic dependency.=20

I intend to experiment with pre-walking any back edges to look for bounds if
there is a cycle.. ie, the range increases or decreases providing an
upper/lower limit.  I just haven't gotten to it yet.    SO no iterations as
such, but a quick pattern check which may provide a bound.

in another PR (107972) I mentioned al alternative VRP which discovers things
from the bottom to the top.. Theres some possibility that pass might expose
this sort of thing too when I get to it.=