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 846B23858C20; Thu,  2 Feb 2023 18:07:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 846B23858C20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675361263;
	bh=TbuZS1ZUP6s5cXlUnyRkHg8/GQkM6EuX5hy/CZBi57U=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=lWenR9lNsC6+BMxWsvnbVaYaZQxqCzn1Vw4Jcb6SPX2GbPKiF6blqv4+qxOfj3HtQ
	 VsZfK+PjdABxoVE1VA9vgrQLritYknHiO2piYgQnBcWsi1jg7sl/kF87Y3T4maX/Ax
	 AqR1eaiHUGyGYhCmVy49YV5YYFKlmVwD2zxGncm4=
From: "jakub at gcc dot gnu.org" <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 18:07:40 +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: jakub at gcc dot gnu.org
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-Ncw4jaDpHS@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 #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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 operator
> for irange is not ICEing for the sub-range comparison (which also have
> different precision), but is dying in the nonzero mask comparison.

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 wi=
th
different types.
It in that case calls tree_int_cst_equal.  But when you switch the boundari=
es
from trees to wide_ints, they will ICE again as well.

I think for the operator=3D=3D, the important question is, shall ranges wit=
h 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 t=
he
caller.
Your patch is changing it to 1), in that case no change would be needed in =
the
particular lh =3D=3D rh user, but are we sure that everywhere where non-com=
patible
types could appear we don't imply from operator=3D=3D returning true that t=
he types
are actually the same?
If we did 2) e.g. by adding a types_compatible_p (type (), b.type ()) check,
then we'd
need to change this lh =3D=3D rh user too, because for the shifts we really=
 just
care about values and not the exact types which can differ.=