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 EDED43858C52; Thu,  2 Feb 2023 19:09:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EDED43858C52
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675364958;
	bh=hG9VZWeG8DGPpBNeTRfp4H3xmC1Z3KGlZnG7k9a+H8M=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Qavphd4CzAHpXmRZjhIYZMvlC+aZPSLVRjWVl8dCogMw8AE7AVpHMsYZYUGyHi9yk
	 KLye4G4ipyBWpl3hEyfScERgMIxvhCw1WxWpz13xg8spxoj85y4VwvM0WpwpVnzCGe
	 DLsp/PbcK8nv8T3Gf+W5v1oAm9ziwgQrzrIZ3Dkw=
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/108639] [13 Regression] ICE on valid code at
 -O1 and above: in decompose, at wide-int.h:984 since r13-5578
Date: Thu, 02 Feb 2023 19:09:18 +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: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108639-4-mq5KQFLU6Q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108639-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108639-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=3D108639

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > (In reply to Jakub Jelinek from comment #3)
> > > Created attachment 54391 [details]
> > > gcc13-pr108639.patch
> > >=20
> > > Untested fix.
> >=20
> > I think the problem is more fundamental than that.  The equality operat=
or
> > for irange is not ICEing for the sub-range comparison (which also have
> > different precision), but is dying in the nonzero mask comparison.
>=20
> Well, that is obvious, because for the actual range boundaries you compare
> trees, not wide_ints.  And operand_equal_p does allow comparing of trees
> with different types.
> It in that case calls tree_int_cst_equal.  But when you switch the
> boundaries from trees to wide_ints, they will ICE again as well.
>=20
> I think for the operator=3D=3D, the important question is, shall ranges w=
ith
> same values but non-compatible types compare
> 1) equal
> 2) non-equal
> 3) be an ICE (e.g. gcc_checking_assert)
> The current state is 3) without the assert and my patch was trying to fix
> the caller.

3) is not a desired result for sure.

I think 1) is our desired outcome... I initially considered 2) as desirable=
 as
we could simply check the types before doing any other work.   As I thought
about it tho, I can't think of any good reason why we would want them to be
unequal.

If they compare equal this way (ignoring type), then performing a cast on
either of them to the same type as the other would also compare equal... its
symmetrical so that actually makes them equal in my book.=