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 A226A3858D38 for ; Thu, 23 May 2024 21:48:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A226A3858D38 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 A226A3858D38 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=1716500895; cv=none; b=Y8BeIMkMOuWBkNq0antdz+01yikFDNfNIldQYYXEidEqyZsB4F00P0Qwuph4xSvwpyzPRLK01nJ2ASQiwkx5P+v9kyNEOLGHuel11APTmG+y8LVp19PRkWnB1ibaCkRQflLfJ05aYSiKGJbtTUxHtahK5mrldpytwEAnJp/bq1w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716500895; c=relaxed/simple; bh=XiSqGT6dn4lxur1cGZ4KvPuegVTbWcOFyQUM9zveQhk=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=OUYNrMWv4z1wLar6fO91KdgAk9leOpFPy80XG5DH1dK3VYhXZsKdxOpkyI8bs/UEwDoefGpoRDscp7FVLHIm73/IrBdmkas+K1/fFrrGGpAhsnxr1Lup+MPSPlgwbFjr3rL0UIOB/I2I/ZP5rDUbr4dTakDFx/D5pnSq1BvX0SI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-169-101.tugraz.at (vra-169-101.tugraz.at [129.27.169.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4VlhcM5rdkz1LXsQ; Thu, 23 May 2024 23:48:03 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4VlhcM5rdkz1LXsQ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1716500884; bh=ybQxQKMxRXbeAhCqBFrO/OEO1YieK93ILyo02LenjEs=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=oPCKbjZ64w33V0IkgAZXH2D84vpk4oxS7Il/l3gcNkqFjsTd9HMPsw5fVv+gyO6+w uVuX0vdAF4joZ6/+ZMevkk/B+s9p434pBkIMFh2vZali7XGwJJUtoFA/4S1q44mOao JA7r7+B/qJuplM7s0M+neikUySmcvUEno9xRyEAU= Message-ID: Subject: Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157] From: Martin Uecker To: Ian Lance Taylor , Joseph Myers Cc: gcc-patches@gcc.gnu.org, Richard Biener , Jakub Jelinek Date: Thu, 23 May 2024 23:47:58 +0200 In-Reply-To: References: <02a9b94e4d653b6f1b9f89a1b62187f46e871738.camel@tugraz.at> <45067a3258e0ec1677ed95f62ac21c1353d66355.camel@tugraz.at> <65955827-eccc-acd0-c8f6-dfd2aaae2cbf@redhat.com> 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 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 Donnerstag, dem 23.05.2024 um 14:30 -0700 schrieb Ian Lance Taylor: > On Thu, May 23, 2024 at 2:00=E2=80=AFPM Joseph Myers wrote: > >=20 > > On Tue, 21 May 2024, Martin Uecker wrote: > > >=20 > > > C: allow aliasing of compatible types derived from enumeral types= [PR115157] > > >=20 > > > Aliasing of enumeral types with the underlying integer is now all= owed > > > by setting the aliasing set to zero. But this does not allow ali= asing > > > of derived types which are compatible as required by ISO C. Inst= ead, > > > initially set structural equality. Then set TYPE_CANONICAL and u= pdate > > > pointers and main variants when the type is completed (as done fo= r > > > structures and unions in C23). > > >=20 > > > PR 115157 > > >=20 > > > gcc/c/ > > > * c-decl.cc (shadow_tag-warned,parse_xref_tag,start_enum, > > > finish_enum): Set SET_TYPE_STRUCTURAL_EQUALITY / TYPE_CAN= ONICAL. > > > * c-obj-common.cc (get_alias_set): Remove special case. > > > (get_aka_type): Add special case. > > >=20 > > > gcc/ > > > * godump.cc (go_output_typedef): use TYPE_MAIN_VARIANT in= stead > > > of TYPE_CANONICAL. > > >=20 > > > gcc/testsuite/ > > > * gcc.dg/enum-alias-1.c: New test. > > > * gcc.dg/enum-alias-2.c: New test. > > > * gcc.dg/enum-alias-3.c: New test. > >=20 > > OK, in the absence of objections on middle-end or Go grounds within the > > next week. >=20 > The godump.cc patch is >=20 > && (TYPE_CANONICAL (TREE_TYPE (decl)) =3D=3D NULL_TREE > || !container->decls_seen.contains > - (TYPE_CANONICAL (TREE_TYPE (decl))))) > + (TYPE_MAIN_VARIANT (TREE_TYPE (decl))= ))) > { >=20 > What is the problem you are seeing? Test failures in godump-1.c >=20 > This patch isn't right: >=20 > 1) The code is saying if "X =3D=3D NULL_TREE || !already_seen(X)". This > patch is changing the latter X but not the former. They should be > consistent. Maybe the X =3D=3D NULL_TREE can be removed if we add TYPE_MAIN_VARIANTs instead? >=20 > 2) At the bottom of that conditional block is code that adds a value > to container->decls_seen. Today that code is adding TYPE_CANONICAL. > If we change the condition to test TYPE_MAIN_VARIANT, then we need to > add TYPE_MAIN_VARIANT to decls_seen. Yes, obviously this is wrong. Thanks! Martin >=20 > Hope that makes sense. >=20 > I don't know why the patch is required, but it's fine with those > changes as long as the libgo tests continue to pass. >=20 > Ian