From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 6B9CF38582AC for ; Thu, 23 Nov 2023 23:48:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B9CF38582AC Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6B9CF38582AC Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=68.232.141.98 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700783284; cv=none; b=qV4Ybyz2NeY1Cjq0Udj7CNDcxWbbEVLnJTzccdl788LL5Bt920YdzYXemmoGNTS9n3WTCi7S4PklTOEBE44rBX1thNRIJbDUI0QO4YY7jVJQaj8yTPPPSbFxieI/l7Sa3vQhKKBdxgZubcqiwf9nPKscrj6r43UtzXTl1hEa8TA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700783284; c=relaxed/simple; bh=/3jFDtgm0TQQiCpsXrMtNlNcVzWR+Cpuad1jaeuiSLk=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=oJXS/ZPRhsAvr6TKGf/ZmtWY01/m9ZnLJjY6katLip4GNqUW1WFEUufGX1cqZXDzQDFSNcGn9oOBbxd/5d7N+6jHMs+36JuVhmx9t3ilqCBw8fIsrD1W1YJRE/7D/TQ9XX1mpWSGcFKd/aYndAXZ2YtlO+zMEMoyf2QnlAgoW4w= ARC-Authentication-Results: i=1; server2.sourceware.org X-CSE-ConnectionGUID: 3vyY89BMRTO3ZnbxrDVyYw== X-CSE-MsgGUID: GfVM8amYQoSn4Zeu+9d0Vw== X-IronPort-AV: E=Sophos;i="6.04,222,1695715200"; d="scan'208";a="26390063" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 23 Nov 2023 15:48:01 -0800 IronPort-SDR: JnYAbvaT1QPWdp7mRNeEzP9e0hZM0pTUbAeHAS7Rq0vkFd5j3ah9/HlWUelSV5VFVvIYQzSmCR KHagvkQu3SLMtSmgzVNsVPU3UoSoTqZtStpOLy+XsEss0yKZaa/FYVK4MMbId0l+KDPEdJLIqB deaLxcGmRgwypQakD0SoVGmVZIBDkf6NHpkzo06TiidOeHXSvpKO4CMTuxS7IvHaeTZWtqJtjm 1XFQ2IeKn/fr2mqU0Pzc8CX7sLUwXc6+WhnyiExII7/yRV77rqtFAGw0BilDvWwalCoWlKhoR6 97g= Date: Thu, 23 Nov 2023 23:47:57 +0000 From: Joseph Myers To: Martin Uecker CC: Subject: Re: [PATCH 3/4] c23: aliasing of compatible tagged types In-Reply-To: <223aa096afbdbb177d4ad5245696d439ad4cf87f.camel@tugraz.at> Message-ID: References: <02a9b94e4d653b6f1b9f89a1b62187f46e871738.camel@tugraz.at> <223aa096afbdbb177d4ad5245696d439ad4cf87f.camel@tugraz.at> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3109.1 required=5.0 tests=BAYES_00,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,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: On Thu, 16 Nov 2023, Martin Uecker wrote: > 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. Is TYPE_CANONICAL *only* used for alias analysis? It's not obvious to me that setting TYPE_CANONICAL to a type that's definitely not equivalent for other purposes is necessarily safe. I also think more rationale is needed for ignoring sizes like this. Is it intended for e.g. making structs with flexible array members alias-compatible with similar structs with a fixed-size array? > @@ -1250,6 +1266,9 @@ comptypes_internal (const_tree type1, const_tree type2, > > if ((d1 == NULL_TREE) != (d2 == NULL_TREE)) > data->different_types_p = true; > + /* ignore size mismatches */ > + if (data->equiv) > + return 1; Should start comment with capital letter, end with '.'. > diff --git a/gcc/testsuite/gcc.dg/c23-tag-2.c b/gcc/testsuite/gcc.dg/c23-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=c23" } > +/* { dg-do compile } > + * { dg-options "-std=c2x" } > */ > > // compatibility of structs in assignment > diff --git a/gcc/testsuite/gcc.dg/c23-tag-5.c b/gcc/testsuite/gcc.dg/c23-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=c23" } > +/* > + * { dg-do run } > + * { dg-options "-std=c2x" } These tests should not be changed to use -std=c2x. > 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=c23 -O2" } > + */ > + > + > +struct foo { int x; }; > + > +int test_foo1(struct foo* a, void* b) > +{ > + a->x = 1; > + > + struct foo { int x; int y; }* p = b; > + p->x = 2; > + > + return a->x; > +} > +int main() > +{ > + struct foo y; > + > + if (1 != test_foo1(&y, &y)) > + __builtin_abort(); This test appears to be testing various invalid cases - testing that the compiler does not consider aliasing to occur in those cases (even though in fact there is aliasing). If that's the intent of this test, it definitely needs commenting. The test would also need to (be a gnu23-* test and) use appropriate attributes to disable interprocedural analysis, since it would be entirely valid for the compiler in this test to inline test_foo1, see that p->x in fact points to the same location as a->x despite the incompatible types, and have the function return 2. The same applies to c23-tag-alias-4.c and c23-tag-alias-5.c. > 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=c23 -O2" } > + */ > + > +// not sure this is wise, but this was already like thi sbefore "this before" -- Joseph S. Myers joseph@codesourcery.com