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 07B133857835; Fri,  3 Feb 2023 14:54:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 07B133857835
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675436093;
	bh=y6rFSuVzqiNNjzAUlEF6zN7/48yn6naMIE7DYm+FTCU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=SiCfKR8yT2vj9MI1drWfQ2pR6HxAHZBBhxMq/06wc+dEgi7p2HSBoSfLX/4XtCWCg
	 Ifnk0RTO8gHgSQyqr4Uf9OiTQ9SK9CH4vG4SmZJtTckq+rC/rAsg3ETgn+eiUIekA2
	 OcHWx9P4IxwrlKWGZlCfujlw+zj2D3FOcO4ZiOuA=
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/108647] [13 Regression] ICE in upper_bound,
 at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
Date: Fri, 03 Feb 2023 14:54:51 +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: 13.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108647-4-3R1Yu7ilGH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108647-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108647-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=3D108647

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
This is the first release that we process relations in GORI.  Up until rece=
ntly
it was fairly ad-hoc what got passed in as a relation trio to the op?_range
routines.  A couple of days ago I fleshed it out fully.  I am surprised that
isn't what caused this.

Anyway, the reason its tripping:

  if (_42 !=3D 0)
    goto <bb 10>; [50.00%]
  else
    goto <bb 6>; [50.00%]

bb6:
  _27 =3D *h_29(D);
  _53 =3D _27 < _42;
  if (_42 > _53)

we start by trying to evaluate the outgoing edge for _42 on the true side:
[1,1] =3D (_42 > _53)
The problem is we have determined that _42 is bool [0, 0] at this point.
Knowing _42 is [0, 0], the definition of _53 can never be true, so it is al=
so
bool [0,0]

in order for _53 to be [0,0] AND _42 to be [0,0], the bool value for _27 is
nonsensical..    and thus its being calculated as undefined.

This branch is eventually going to be removed since it can never be taken, =
but
that hasnt happened at this point yet.

we could fix it at the call site, but you do point out that the opX_range
routines are not gracefully dealing with undefined values.

We probably should audit them all to make sure we handled undefined gracefu=
lly
before accessing a bound.=