From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 7FDC43858C50 for ; Mon, 17 Jun 2024 13:33:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7FDC43858C50 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7FDC43858C50 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718631191; cv=none; b=Qan/iN+8O6Qh7ztOiG2Yj1IqR/qKyrN5S8wDCo3mDzrlLvB7aR5LxWKJKHZ8EVENawSlfnxWt6MAtbb88rhkOSnrP7aDoCuDCTNfwMan2TSG6QEwyCyK6Af8omIX2ZNZ33cc4NeekKOXs31TUXGWj08bf1unFdjZ1J/rOc+j81k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718631191; c=relaxed/simple; bh=24XSNbtS9WUxy3wQW+MkwdK0BlW4f7kRri6Ka1pGKj8=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=wNi7ZTwl/992m+FJI8wlBFduqXfZ8I/SoVuIDes5aKJy/dDo09ZkqTRBe/eWUOF0wYw2NjN8Mcapiq9pGhAb8MahTp2o3XbdkUswGFQ2cWHxstKES+9+Kn/asI2+5JciqHSaSS7pu5lgowkQXksYeLpDxCRDypk0mUGDxh+mYQg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from tug-swl-225-150.tugraz.at (tug-swl-225-150.tugraz.at [129.27.225.150]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4W2rRj5JF1z3wCn; Mon, 17 Jun 2024 15:33:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1718631186; bh=STHL+bVz8VKj8t11NY1nrAGZ+OCbzbU6Z3BjYRw2KMw=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=JJeE1VK8mVmJPJWo24sLwAEDbwBN+73DYPHNq/3uvE6Urb+x7ux/i5jMGSz8ncPMW jHLiGTGD1u54SJ0xvRCYF59Nnf0/1bhjOZXYP4iy4vEKrpN9k/y68Tq3JftgMHPmFS AOXjpigoYTcjBfaAd98fX55eO7zAFU4JVcy7PrMg= Message-ID: Subject: Re: check_qualified_type From: Martin Uecker To: Jakub Jelinek , Richard Biener Cc: gcc@gcc.gnu.org, Joseph Myers Date: Mon, 17 Jun 2024 15:33:05 +0200 In-Reply-To: References: <147dbd85269a23623a7a33a862c1cfa4232aae84.camel@tugraz.at> <4aca9f8d18b29e4a6fd925477ca1d9a451992c8a.camel@tugraz.at> <24n46r00-qp22-r358-0qq6-q8s11rr89rp9@fhfr.qr> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Montag, dem 17.06.2024 um 14:57 +0200 schrieb Jakub Jelinek: > On Mon, Jun 17, 2024 at 02:42:05PM +0200, Richard Biener wrote: > > > > > I am trying to understand what check_qualified_type > > > > > does exactly. The direct comparison of TYPE_NAMES seems incorrect > > > > > for C and its use is c_update_type_canonical then causes > > > > > PR114930 and PR115502. In the later function I think > > > > > it is not really needed and I guess one could simply remove > > > > > it, but I wonder if it works incorrectly in other cases=C2=A0 > > > > > too? > > > >=20 > > > > TYPE_NAMES is compared because IIRC typedefs are recorded as varian= ts > > > > and 'const T' isn't the same as 'const int' with typedef int T. > > >=20 > > > so if it is intentional that it differentiates between=20 > > >=20 > > > struct foo > > >=20 > > > and > > >=20 > > > typedef struct foo bar > > >=20 > > > then I will change c_update_type_canonical to not use it, > > > because both types should have the same TYPE_CANONICAL > >=20 > > The check is supposed to differentiate between variants and all variant= s > > have the same TYPE_CANONICAL so I'm not sure why you considered using > > this function for canonical type compute? >=20 > I've done that and that was because build_qualified_type uses that > predicate, where qualified types created by build_qualified_type have > as TYPE_CANONICAL the qualified type of the main variant of the canonical > type, while in all other cases TYPE_CANONICAL is just the main variant of > the type. > Guess we could also just do > if (TYPE_QUALS (x) =3D=3D TYPE_QUALS (t)) > TYPE_CANONICAL (x) =3D TYPE_CANONICAL (t); > else if (TYPE_CANONICAL (t) !=3D t > || TYPE_QUALS (x) !=3D TYPE_QUALS (TYPE_CANONICAL (t))) > TYPE_CANONICAL (x) > =3D build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x= )); > else > TYPE_CANONICAL (x) =3D x; >=20 Ok, that works. I think the final "else" is then then impossible to reach and can be eliminated as well, because if TYPE_CANONICAL (t) =3D=3D t then= =20 TYPE_QUALS (x) =3D=3D TYPE_QUALS (TYPE_CANONICAL (t)) is identical to TYPE_QUALS (x) =3D=3D TYPE_QUALS (t) which is the first case. Martin