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 B57EB3858C50 for ; Tue, 28 Nov 2023 11:51:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B57EB3858C50 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 B57EB3858C50 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=1701172276; cv=none; b=M3+9syKAOPNXjiukm1H+2gMSaGiqm29dbsFg65+vXCdRTyDcmZiSoB87QJExcSfcHbvE7y3Vr6BCyZt7Sk6J3SFvj3VfUa3UmFdZqRz1NTEUV43HkdwjedqkIvdBT3axiG9dzBNlBzm0NvNJ4DimwZB9JHqkFcVCddHEjrVHYmw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701172276; c=relaxed/simple; bh=xtQ4AfRUubBlZgCPXaJrTNtqUi25yy8mOeJDPim3qYQ=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=ULKijh5/ClwEnZO0opeIsgava1g4hwuhlzTIIGlc8k76R4pbJfXkUHr/NXT3l9WmiWvKYh8+OojlCsGDl7lrDbEffezOGj/fN41J0rTfJfhLbE166dfHDvXeI9LcSdr7fMMIM4jdhKW0pysxZBS0kdTkLfZNpmlnGHZSXhzkogY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fbmtpc21.tugraz.at (fbmtpc21.tugraz.at [129.27.144.40]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SfglL3NPVz3wD0; Tue, 28 Nov 2023 12:51:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1701172270; bh=3aLseRoq9ziDHb8XjNE4QLj326t/01A81NNnRT1NNhU=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=KYj3W8nilq/e83moAkm6FibJR7tBgLQXTJmw8au2/45YOKFxw69Sud1pFC1V5yWC8 nvFVRom1SeRUVtOO2DdCVTIYeCCah/OumGAnkvoOgRwOtw294AHnmTrV981sS/sjyq jFKcz7swmSY2Otbvph3/RzzhB+5VLHWEfX5tzlm0= Message-ID: Subject: Re: [PATCH 3/4] c23: aliasing of compatible tagged types From: Martin Uecker To: Richard Biener , Joseph Myers Cc: gcc-patches@gcc.gnu.org Date: Tue, 28 Nov 2023 12:51:10 +0100 In-Reply-To: References: <02a9b94e4d653b6f1b9f89a1b62187f46e871738.camel@tugraz.at> <223aa096afbdbb177d4ad5245696d439ad4cf87f.camel@tugraz.at> <4337947e3d85a6796567eceb7e3470db6327f7a8.camel@tugraz.at> <47966764-3dd6-8499-a798-c497dab393d@codesourcery.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.116 X-Spam-Status: No, score=-4.6 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 Dienstag, dem 28.11.2023 um 10:47 +0000 schrieb Richard Biener: > On Tue, 28 Nov 2023, Joseph Myers wrote: >=20 > > On Sun, 26 Nov 2023, Martin Uecker wrote: > >=20 >=20 > > > > I also think more rationale is needed for ignoring sizes like this.= Is it=20 > > > > intended for e.g. making structs with flexible array members=20 > > > > alias-compatible with similar structs with a fixed-size array? > > >=20 > > > The main reason are pointers to arrays: > > >=20 > > > struct foo { int (*x)[]; } > > > struct foo { int (*x)[2]; }; > > > struct foo { int (*x)[1]; }; > >=20 > > Thanks for the explanation. > >=20 > > I guess the cases involving flexible array members actually show up a b= ug=20 > > in the standard rather than any kind of issue with this patch - the=20 > > standard allows one structure ending with a flexible array member, and= =20 > > another ending with a fixed-size array, to be compatible (and in differ= ent=20 > > translation units allowed that even before C23), but there is also clea= r=20 > > text in the standard showing it's not intended to require the layout to= be=20 > > consistent (the fixed-size and flexible arrays might have different=20 > > offsets), and what you'd actually get with an assignment or conditional= =20 > > expression mixing such structures certainly isn't clearly specified. = =20 > > Maybe the right resolution for that issue with the standard would be to= =20 > > make that particular case incompatible, but it would need to be raised = as=20 > > an issue after C23 is out. >=20 > I think from a middle-end perspective it's desirable that accessing > either of the foo with size 2 and 1 through a pointer of the type > of the foo with unknown size is permissible from a TBAA view. But > it's not clear to me that accessing the foo with array size 2 via > an lvalue of the type of foo with array size 1 is required to be > supported (from a TBAA view). This is the same from the C language side. In principle, accesses=C2=A0 to an object with effective type foo [2] using an lvalue of type=C2=A0 foo [1] or vice versa are undefined behavior. So a model based on equivalence classes loses some information.=20 Martin