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 9703E3858CD1 for ; Sun, 26 Nov 2023 22:48:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9703E3858CD1 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 9703E3858CD1 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=1701038935; cv=none; b=MppJcBw2wtBGnUTmQWkwA3Uuf4ihi8il3N+NQhlXhjOampxQ3UfZkTWPcWJ6vqBg2MmxNsMN9F0eB4E85AOOlWibiPR/8uMu+d0siVYEPqKKolJITVlNeaf94AiZoJX/r2CAZQyeXTxmhrpjRj5v8cKQQn/iNAc9uHixnu6lLzo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701038935; c=relaxed/simple; bh=h/KhA/7AA6KUuiiawZsk4/XC0oUt18qZZ4uBBtzpI1A=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=KNxBXfURwMfPKwKigqbmZmwTTnacqee5am1inmq+aBI7enJcECcXSGzZ95V5KWi15cAREL/rcpBTqMsA0ZhJOibI0F33ZL5Xb6TshA5mmFUAk629m0wp3bD/WW3zK3KglGxpPyiLiriueqC9KITRGhNxKzUQbbWbSN8DUWTQCnA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-173-22.tugraz.at (vra-173-22.tugraz.at [129.27.173.22]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SdkR55gcJz3wlQ; Sun, 26 Nov 2023 23:48:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1701038930; bh=XHPDP9QwMe0rje8ZuB8vKsd94CLBzKYF2yIcvH7gt4E=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=qlL6K5G3z5cE6+HDn+8NCSiJNq82S0qku3deXgtp3dUVZGxRxif8DnbZqIcrm07Pb 3/jwJufEYqr9DXbUP2cpQfg3tSNvh9XhQC6vT7eWwUiN4iUNVxJ7pqYeG12aevxu4h Zz9egHhmjSn3GpnIHqugaWHwXE+TOcvQBRXOdpD4= Message-ID: <4337947e3d85a6796567eceb7e3470db6327f7a8.camel@tugraz.at> Subject: Re: [PATCH 3/4] c23: aliasing of compatible tagged types From: Martin Uecker To: Joseph Myers Cc: gcc-patches@gcc.gnu.org, Richard Biener Date: Sun, 26 Nov 2023 23:48:49 +0100 In-Reply-To: References: <02a9b94e4d653b6f1b9f89a1b62187f46e871738.camel@tugraz.at> <223aa096afbdbb177d4ad5245696d439ad4cf87f.camel@tugraz.at> 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.116 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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: Thanks Joseph, I will sent an updated series tomorrow.=20 Richard, maybe you could look at what I wrote below about my use of TYPE_CANONICAL ? Does this make sense? Am Donnerstag, dem 23.11.2023 um 23:47 +0000 schrieb Joseph Myers: > On Thu, 16 Nov 2023, Martin Uecker wrote: >=20 > > Tell the backend which types are equivalent by setting > > TYPE_CANONICAL to one struct in the set of equivalent > > structs. Structs are considered equivalent by ignoring > > all sizes of arrays nested in types below field level. >=20 > Is TYPE_CANONICAL *only* used for alias analysis? It's not obvious to me= =20 > that setting TYPE_CANONICAL to a type that's definitely not equivalent fo= r=20 > other purposes is necessarily safe. My understand is that it is used for aliasing analysis and also checking of conversions. TYPE_CANONICAL must be consistent with the idea the middle-end has about type conversions. But as long as we do not give the same TYPE_CANONICAL to types the middle-end thinks must be incompatible using its own type checking machinery, it should=C2=A0be safe even for types the C standard thinks must be incompatible for some reason. > I also think more rationale is needed for ignoring sizes like this. Is i= t=20 > intended for e.g. making structs with flexible array members=20 > alias-compatible with similar structs with a fixed-size array? The main reason are pointers to arrays: struct foo { int (*x)[]; } struct foo { int (*x)[2]; }; struct foo { int (*x)[1]; }; So at least when putting it in terms of equivalence classes, one has no choice than making those types equivalent. So all those would get the same TYPE_CANONICAL. The middle-end=C2=A0 does not care about the different pointer types (in useless_type_conversion_p or gimple_canonical_types_compatible_p). Martin >=20 > > @@ -1250,6 +1266,9 @@ comptypes_internal (const_tree type1, const_tree = type2, > > =20 > > if ((d1 =3D=3D NULL_TREE) !=3D (d2 =3D=3D NULL_TREE)) > > data->different_types_p =3D true; > > + /* ignore size mismatches */ > > + if (data->equiv) > > + return 1; >=20 > Should start comment with capital letter, end with '.'. >=20 > > diff --git a/gcc/testsuite/gcc.dg/c23-tag-2.c b/gcc/testsuite/gcc.dg/c2= 3-tag-2.c > > index 5dd4a21e9df..e28c2b5eea2 100644 > > --- a/gcc/testsuite/gcc.dg/c23-tag-2.c > > +++ b/gcc/testsuite/gcc.dg/c23-tag-2.c > > @@ -1,5 +1,5 @@ > > -/* { dg-do compile { target { ! "*-*-*" } } } > > - * { dg-options "-std=3Dc23" } > > +/* { dg-do compile } > > + * { dg-options "-std=3Dc2x" } > > */ > > =20 > > // compatibility of structs in assignment > > diff --git a/gcc/testsuite/gcc.dg/c23-tag-5.c b/gcc/testsuite/gcc.dg/c2= 3-tag-5.c > > index ff40d07aef1..95a04bf9b0e 100644 > > --- a/gcc/testsuite/gcc.dg/c23-tag-5.c > > +++ b/gcc/testsuite/gcc.dg/c23-tag-5.c > > @@ -1,5 +1,6 @@ > > -/* { dg-do run { target { ! "*-*-*" } } } > > - * { dg-options "-std=3Dc23" } > > +/* > > + * { dg-do run } > > + * { dg-options "-std=3Dc2x" } >=20 > These tests should not be changed to use -std=3Dc2x. >=20 > > diff --git a/gcc/testsuite/gcc.dg/c23-tag-alias-2.c b/gcc/testsuite/gcc= .dg/c23-tag-alias-2.c > > new file mode 100644 > > index 00000000000..555c30a8501 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.dg/c23-tag-alias-2.c > > @@ -0,0 +1,73 @@ > > +/* > > + * { dg-do run } > > + * { dg-options "-std=3Dc23 -O2" } > > + */ > > + > > + > > +struct foo { int x; }; > > + > > +int test_foo1(struct foo* a, void* b) > > +{ > > + a->x =3D 1; > > + > > + struct foo { int x; int y; }* p =3D b; > > + p->x =3D 2; > > + > > + return a->x; > > +} >=20 > > +int main() > > +{ > > + struct foo y; > > + > > + if (1 !=3D test_foo1(&y, &y)) > > + __builtin_abort(); >=20 > This test appears to be testing various invalid cases - testing that the= =20 > compiler does not consider aliasing to occur in those cases (even though= =20 > in fact there is aliasing). >=20 > If that's the intent of this test, it definitely needs commenting. The= =20 > test would also need to (be a gnu23-* test and) use appropriate attribute= s=20 > to disable interprocedural analysis, since it would be entirely valid for= =20 > the compiler in this test to inline test_foo1, see that p->x in fact=20 > points to the same location as a->x despite the incompatible types, and= =20 > have the function return 2. >=20 > The same applies to c23-tag-alias-4.c and c23-tag-alias-5.c. >=20 > > diff --git a/gcc/testsuite/gcc.dg/c23-tag-alias-5.c b/gcc/testsuite/gcc= .dg/c23-tag-alias-5.c > > new file mode 100644 > > index 00000000000..4e956720143 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.dg/c23-tag-alias-5.c > > @@ -0,0 +1,30 @@ > > +/* { dg-do run } > > + * { dg-options "-std=3Dc23 -O2" } > > + */ > > + > > +// not sure this is wise, but this was already like thi sbefore >=20 > "this before" >=20