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 18B233858404 for ; Mon, 18 Mar 2024 15:14:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18B233858404 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 18B233858404 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=1710774843; cv=none; b=rmDgfVmzkLxc4OXarPFqTmcBvw1WVN6HeimqD1/MCzVasr1BiGZnjifaCXqTdWt1ZX2la9OPW+Hv0xNw9P2eR7uwXPRugv6jolhR7pvo3rIL2xN7AhUuBK3E7U4nfdyHfDbSMG4xciVleCuo0JNjH110Un3XOFJ7wGNv8nOtXA4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710774843; c=relaxed/simple; bh=sS8E2RxviKzQLBlj997SSZKjYVvautJXDSWvGArXHdc=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=Mu4oNJMIv2tPyM6kaLsMeCGFelVHBknOShEzOxl8ooGE+NFUPVouLv7xSP44XfeSsgKHkrpXLbybAx+TINyGL4OeX5Dik1iOtgupT6s4bAc4g60B24cuteD7KEhjQIMPrBxTEzOjZRWdkG8ZBApTMEporG1dRCx0Tg3LZ1L9LDk= 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 4Tyz066Yjdz1LM0F; Mon, 18 Mar 2024 16:13:58 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4Tyz066Yjdz1LM0F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1710774838; bh=Hg6QRZ9roGn3ZyK6rujXrCuuPQJvDdkn8VGu+KMI0q8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=N7kwYrWQLQVhXM3kjPvhDc4AaYoYr9I2cMbINN6LM9dK72QV7ngiY4c5ir3eCq9QD MHs/osXS338qADXCOxGL6xLC2X32n0xJcs6P6DWccwf3BkL7zDT+jfVjieikKPKLzU dvG0jf72TCGUT0M+JDiOUwV5BQIYttjz6432vhJU= Message-ID: <325cbb9bc55d709dbe1402b179568a3d9c8b56d5.camel@tugraz.at> Subject: Re: aliasing From: Martin Uecker To: Richard Biener Cc: gcc@gcc.gnu.org Date: Mon, 18 Mar 2024 16:13:58 +0100 In-Reply-To: References: <80d108c853404b7f1e48bf001db37d94e6651f42.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=-4.3 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 Montag, dem 18.03.2024 um 14:21 +0100 schrieb Richard Biener: > On Mon, Mar 18, 2024 at 12:56=E2=80=AFPM Martin Uecker = wrote: > >=20 > > Am Montag, dem 18.03.2024 um 11:55 +0100 schrieb Martin Uecker: > > > Am Montag, dem 18.03.2024 um 09:26 +0100 schrieb Richard Biener: > > > > On Mon, Mar 18, 2024 at 8:03=E2=80=AFAM Martin Uecker wrote: > > > >=20 > > >=20 > > > >=20 > > > > Let me give you an complication example made valid in C++: > > > >=20 > > > > struct B { float x; float y; }; > > > > struct X { int n; char buf[8]; } x, y; > > > >=20 > > > > void foo(struct B *b) > > > > { > > > > memcpy (x.buf, b, sizeof (struct B)); // in C++: new (x.buf) B (= *b); > > >=20 > > > Let's make it an explicit store for the moment > > > (should not make a difference though): > > >=20 > > > *(struct B*)x.buf =3D *b; > > >=20 > > > > y =3D x; // (*) > > > > } > > > >=20 > > > > What's the effective type of 'x' in the 'y =3D x' copy? > > >=20 > > > Good point. The existing wording would take the declared > > > type of x as the effective type, but this may not be > > > what you are interested in. Let's assume that x has no declared > > > type but that it had effective type struct X before the > > > store to x.buf (because of an even earlier store to > > > x with type struct X). > > >=20 > > > There is a general question how stores to subobjects > > > affect effective types and I do not think this is clear > > > even before this proposed change. > >=20 > > Actually, I think this is not allowed because: > >=20 > > "An object shall have its stored value accessed only by an > > lvalue expression that has one of the following types: > >=20 > > =E2=80=94 a type compatible with the effective type of the object, > > ... > > =E2=80=94 an aggregate or union type that includes one of the > > aforementioned types among its members (including, > > recursively, a member of a subaggregate or contained union), or > >=20 > > =E2=80=94 a character type." > >=20 > > ... and we would need to move "a character type" above > > in the list to make it defined. >=20 > So after >=20 > *(struct B*)x.buf =3D *b; >=20 > 'x' cannot be used to access itself? In particular also > an access to 'x.n' is affected by this? According to the current wording and assuming x has no a declared type, x.buf would acquire an effective=C2=A0 type of struct B. Then if x.buf is read as part of=C2=A0 a x it is accessed with an lvalue of struct X (which does not include a struct B but a character buffer). So yes, currently it would=C2=A0 be undefined behavior=C2=A0 and the proposed wording would=C2=A0not change this. Clearly, we should include an additional change to fix this. >=20 > You are right that the current wording of the standard doesn't > clarify any of this but this kind of storage abstraction is used > commonly in the embedded world when there's no runtime > library providing allocation. And you said you want to make > the standard closer to implementation practice ... Well, we are working on it... Any help is much appreciated. >=20 > Elsewhere when doing 'y =3D x' people refer to the wording that > aggregates are copied elementwise but it's not specified how > those elementwise accesses work - the lvalues are still of type > X here or are new lvalues implicitly formed and fall under the > other wordings?=C2=A0 I think there is no wording for elementwise copy. My understanding is that the=C2=A0 "...an aggregate or union type that includes..." wording above is supposed to define this via an lvalue access with aggregate or union type. It blesses the implied access to the elements via the access with=C2=A0 an lvalue which has the type of the aggregate. =20 > Can I thus form an effective type of X by > storing it's subobjects at respective offsets (ignoring padding, > for example) and can I then use an lvalue of type 'X' to access > the whole aggregate? I think this is defined behavior. The subjects get their effective types via the individual stores and then=C2=A0 the access using lvalue of type 'X' is ok according to the "..an aggregate or union type that includes.." rule. Martin