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 DE2F13858D32; Mon,  5 Sep 2022 08:27:54 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE2F13858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1662366474;
	bh=IwXo250CVhtyKJ+nCWK2UoiDykayIckHZhTPZ8+RZ28=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=pQ7/FNM4C8vYzi8AR3xkwNZcRcjK/I1LeK8rtTmLJBrn4fyX172rEBnSd2mCejlSS
	 8Rs6DjbQfK6JfOHEEYltkjzozJlGH7TQPauZUaNWr0hLSJEZwFBwQcM/WfCaj7lt00
	 DX0Yz+csamNRJvxeh0cZ6dDD2H/Yw9dlKjHaMv5Y=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/106833] Handle OPAQUE_TYPE in
 gimple_canonical_types_compatible_p
Date: Mon, 05 Sep 2022 08:27:54 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: ice-checking
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106833-4-rlPBKDdwud@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106833-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106833-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=3D106833

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> (In reply to Kewen Lin from comment #1)
> > IMHO this is an omission when we were adding supports for opaque type, =
const
> > __vector_quad and __vector_quad should be taken as
> > canonical_types_compatible.
> >=20
> > I wonder if we can simply take it just like what it handles for
> > "Non-aggregate types", for example:
> >=20
> > diff --git a/gcc/tree.cc b/gcc/tree.cc
> > index 2f488e4467c..555e96c59d5 100644
> > --- a/gcc/tree.cc
> > +++ b/gcc/tree.cc
> > @@ -13510,6 +13510,7 @@ gimple_canonical_types_compatible_p (const_tree=
 t1,
> > const_tree t2,
> >        || TREE_CODE (t1) =3D=3D VECTOR_TYPE
> >        || TREE_CODE (t1) =3D=3D COMPLEX_TYPE
> >        || TREE_CODE (t1) =3D=3D OFFSET_TYPE
> > +      || TREE_CODE (t1) =3D=3D OPAQUE_TYPE
> >        || POINTER_TYPE_P (t1))
> >      {
> >        /* Can't be the same type if they have different recision.  */
> >=20
> > Or adding one default hook which does the similar thing, and then if one
> > target needs some target specific checks on its opaque type, one specif=
ic
> > hook can be provided.
>=20
> I'm quoting tree.def, emphasis mine:
>=20
> /* This is for types that will use MODE_OPAQUE in the back end.  They are
> meant
>    to be able to go in a register of some sort but are _EXPLICITLY NOT TO=
 BE
>    CONVERTED_ or operated on like INTEGER_TYPE.  They will have size and
>    alignment information only.  */
> DEFTREECODE (OPAQUE_TYPE, "opaque_type", tcc_type, 0)

Also the above says "have size and alignment information only" but the
path you patch will look at TYPE_PRECISION and signedness.  Why, if that
was necessary, did the TYPE_MODE check not trigger?

> so why should we care about special-casing them?  The target should have =
set
> TYPE_CANONICAL appropriately if necessary, why didn't it?  Btw, 'const'
> qualification should go into the type variant chain (well, for "normal"
> types), where TYPE_MAIN_VARIANT is the unqualified type variant.=20
> TYPE_CANONICAL
> shouldn't come into play here.
>=20
> Btw, the whole idea of "opaque" is a hack and it seems to backfire now?=