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 5C4443858C53 for ; Tue, 28 Nov 2023 01:00:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5C4443858C53 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 5C4443858C53 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=1701133236; cv=none; b=esZcnzpmRNZN5DGV/wVgqSNt/l2D1K82l4hTRDgNFMYsdQGtrmr/qQcCgo+vp+NLoYTeudFbsdIE4NVpeOpg1YtEyHk4kNKoZY48ETiFN3KXpKFqG1+Wq6SQ9x6r87/8qdMETfwaa1UTVBcQvo70hSaIImG+iuWtnwzTjDXHoSU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701133236; c=relaxed/simple; bh=9jX5jr01LCSmW9LNWlBPpvHUnFoOJJGjMPnZqO/p07g=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=Q4WD1ba14PTGtHRyWUG3iBJH/UZKtcohIysWzcSy5jH54vQGDBcaXaqKr/hOJN6wzGmea4ziyXq3vRgc5ZDr8Qw2CO8aBqJ4Nrff8D5eXA89bpDD66e/quKiGzOzZqw9WiHbyYvXaXvamunTjFExtO36iHBb9v2MahrCpEQkvJM= ARC-Authentication-Results: i=1; server2.sourceware.org X-CSE-ConnectionGUID: eOCYloc8SbyrFAnyczttoQ== X-CSE-MsgGUID: KhXQvHfbREuJ7vF3/AqXSw== X-IronPort-AV: E=Sophos;i="6.04,232,1695715200"; d="scan'208";a="26696411" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 27 Nov 2023 17:00:33 -0800 IronPort-SDR: SPnOFiM62zOTk16e/tFsnvf36owkc/n/HsDiGWQ1398UrULgsnATEc0vSQOz6sbIwxDJD5ggRb NQ3mjwgApOsifdjSBq0J39pIsE+T8PxVPv30/eymCvMGMWqYII+yHx7Ylg9AoT+uFcNACqqVlX tguLFvOvNG572LlXAAQ5xmZ7zOR2FU6x8ZeBcIr9n7aqXS719VnzwOVPoDSsSvDr9g5fJUMbY6 tJXMUHFSgHSqc6wv88rfOAyh0k0+ZdyTOxEC3H4EI6SlKLKhR/IRewAoJ0JKtlKeAheZ2KZFN7 /Bw= Date: Tue, 28 Nov 2023 01:00:30 +0000 From: Joseph Myers To: Martin Uecker CC: , Richard Biener Subject: Re: [PATCH 3/4] c23: aliasing of compatible tagged types In-Reply-To: <4337947e3d85a6796567eceb7e3470db6327f7a8.camel@tugraz.at> Message-ID: <47966764-3dd6-8499-a798-c497dab393d@codesourcery.com> References: <02a9b94e4d653b6f1b9f89a1b62187f46e871738.camel@tugraz.at> <223aa096afbdbb177d4ad5245696d439ad4cf87f.camel@tugraz.at> <4337947e3d85a6796567eceb7e3470db6327f7a8.camel@tugraz.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-1604126478-1701133230=:2907887" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3103.0 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: ---1152306461-1604126478-1701133230=:2907887 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Sun, 26 Nov 2023, Martin Uecker wrote: > 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 be safe even for types the C standard thinks must be > incompatible for some reason. And presumably also for types that definitely can't be assigned because they have incompatible layout through the use of different array sizes - since the front end won't generate such assignments, it would never matter whether the middle end considers them valid without conversion or not? > > 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? > > The main reason are pointers to arrays: > > struct foo { int (*x)[]; } > struct foo { int (*x)[2]; }; > struct foo { int (*x)[1]; }; Thanks for the explanation. I guess the cases involving flexible array members actually show up a bug in the standard rather than any kind of issue with this patch - the standard allows one structure ending with a flexible array member, and another ending with a fixed-size array, to be compatible (and in different translation units allowed that even before C23), but there is also clear text in the standard showing it's not intended to require the layout to be consistent (the fixed-size and flexible arrays might have different offsets), and what you'd actually get with an assignment or conditional expression mixing such structures certainly isn't clearly specified. Maybe the right resolution for that issue with the standard would be to make that particular case incompatible, but it would need to be raised as an issue after C23 is out. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-1604126478-1701133230=:2907887--