From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CB3133857BA6; Mon, 5 Sep 2022 09:26:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CB3133857BA6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662369967; bh=m75M+JvQfWIXO03NqmJBt4M0BqsgrYF2m9c2R8VWqCo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HEyxbU6+WiVnHIQnj1lRaNXcVZwDeQ0bAUAwFDAU6iaak30BO6aEhIHxz6DmmuvJw e27lV87U+VlRpUp3ItJcRpUKOimlOHkn/jGBVqVobtyaf+Z6TL5lDx8wk3GY6wK7mN dsZeWZJ95DYIBfo+9GV+Zgl8IrjWaveUzqAzUig4= From: "linkw at gcc dot 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 09:26:07 +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: linkw 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106833 --- Comment #4 from Kewen Lin --- (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) >=20 Good point! My fault, I didn't read through this documentation. It seems to= say no conversions are allowed on it? (either explicit or implicit?) > 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 With flag_checking on, while doing lto_fixup_state, verify_type will check every tree type, it further checks with verify_type_variant, then fails with gimple_canonical_types_compatible_p (t, tv, false). (here trust_type_canon= ical is false). I think this is a common issue for any cv-qualified opaque type when lto checking is on. In this case,=20 t1: const __vector_quad=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 t2: __vector_quad Both TYPE_MAIN_VARIANT and both TYPE_CANONICAL is exactly the same here (all equivalent to t2). > Btw, the whole idea of "opaque" is a hack and it seems to backfire now? Not sure, it had some adjustments with r11-5222 before, I thought we need s= ome similar for this issue.=