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 511FC3858C60; Tue, 13 Feb 2024 09:52:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 511FC3858C60
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707817925;
	bh=zB8oyZUuLDE8WGqmmDHDDed45QV1EPok6dTAQnhcN8M=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=xA0dq0Oztbm3TS9yWzUfZ9B1WYrMCAQXpRg/zvngYjyc2X07wmMCuXE4JQnFHj9/T
	 tBt7llGKVM2bYfxMer7CX0xpSdcalH8bJ2WEXh5Y20Hi8Jg8wS8SC3Z6Gre8LE/WyA
	 YVj8lDwdQMIX7hDe7y6ChSRI5WyLqWu+KNr3aHig=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/113895] [14 Regression] ice in in
 copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
Date: Tue, 13 Feb 2024 09:52:02 +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: 14.0
X-Bugzilla-Keywords: ice-checking, ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113895-4-Gr0mO79QsA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113895-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113895-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=3D113895

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
_1 =3D a[b.1_14][7];

we "correctly" resolve b.1_14 to 1 based on range info which is
[-INF,-1] [1, +INF].  The thing is, the get_ref_base_and_extent code
cannot do anything with this range but adjusting max_size to 32
by taking [7] and the overall size of a[] (8 elements) into account.

The reverse-engineering of a constant array index falls apart when facing
with this kind of undefined behavior - and it's the checking code trying
to verify both implementations against each other that fails.

That said, it's

                tree asize =3D TYPE_SIZE (TREE_TYPE (TREE_OPERAND (exp, 0))=
);
                /* We need to adjust maxsize to the whole array bitsize.
                   But we can subtract any constant offset seen so far,
                   because that would get us outside of the array otherwise=
.=20
*/
                if (known_size_p (maxsize)
                    && asize
                    && poly_int_tree_p (asize))
                  maxsize =3D wi::to_poly_offset (asize) - bit_offset;

that ends up constraining the access, but the resulting offset is
to a[1][3], and VN comes up with a[1][7].=