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 F20A73858C5F for ; Mon, 18 Mar 2024 10:55:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F20A73858C5F 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 F20A73858C5F 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=1710759352; cv=none; b=j62288mRqdi7ZeVv7VCFEY5zEcHOpDgZqbPHrwfMMlgBoKP/4x/vAJCJSEPc2ziNGK3DPqwqdRizmcimqUebTWLmWlvCksdv664NOPpxEfcBUlpcxb40z675CsoRCwa9TpB1SzOta7UAbzRkqFEmdlqX3QuML+Nxbq1zlb1WYr0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710759352; c=relaxed/simple; bh=+eb+LIQFrnDlq5WzYJEOFkXwgKIuEXuyU768Tseg0go=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=XWh1gbrVpXPC1NAQumfLhgaz+h2+JzCNTTOkE1nFhw5Oj+wNvHIqG87nxI4HrqtaU/1MRf0m6Lk4GfcOdG3MOExbHVJW9HfFh99l/1MsV4gf0qlPhbF/5nR2KNB0SJ4BchQFHAfwwMs4lfpXHCXPuW+nJBjXrhPv312eBU0dkTU= 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 4TysGB6Kwjz3wXB; Mon, 18 Mar 2024 11:55:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1710759346; bh=QqYc4LGxc0BwNTvS1Gv+oEq3mu0JrbBbM7GspYloR00=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=CfVJaITDu2bOsFpieDJZd4obZiXSjJYGH2JPWE2Q8OFGMfVpj2i/cDE2Sj37XgIn8 gsRhYhCiY7FV/fOF77Cw3GqImI8q1fiZZZ2hxlBz6TuXFhjU1zzxVTF+mVAJMju3pT 7DM6Xy5szD4rOIKGL7954D69bQ+XUN9Jme8gNm1s= Message-ID: <80d108c853404b7f1e48bf001db37d94e6651f42.camel@tugraz.at> Subject: Re: aliasing From: Martin Uecker To: Richard Biener Cc: gcc@gcc.gnu.org Date: Mon, 18 Mar 2024 11:55:46 +0100 In-Reply-To: References: 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.4 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 09:26 +0100 schrieb Richard Biener: > On Mon, Mar 18, 2024 at 8:03=E2=80=AFAM Martin Uecker = wrote: > >=20 > >=20 > > Hi, > >=20 > > can you please take a quick look at this? This is intended to align > > the C standard with existing practice with respect to aliasing by > > removing the special rules for "objects with no declared type" and > > making it fully symmetric and only based on types with non-atomic > > character types being able to alias everything. > >=20 > >=20 > > Unrelated to this change, I have another question: I wonder if GCC > > (or any other compiler) actually exploits the " or is copied as an > > array of byte type, " rule to make assumptions about the effective > > types of the target array? >=20 > We do not make assumptions about this anymore. We did in the > past (might be a distant past) transform say >=20 > struct X { int i; float f; } a, b; >=20 > void foo () > { > __builtin_memcpy (&a, &b, sizeof (struct X)); > } >=20 > into >=20 > a =3D b; >=20 > which has an lvalue of type struct X. But this assumed b's effective > type was X. Nowadays we treat the copy as using alias set zero. > That effectively means the destination gets its effective type "cleared" > (all subsequent accesses are valid to access storage with the effective > type of a byte array). Ok, thanks! I wonder whether we should remove this special rule from the standard. I mostly worried about the "copied as an array of byte type" wording which seems difficult to precisely define. >=20 > > I know compilers do this work memcpy... > > Maybe also if a loop is transformed to memcpy? >=20 > We currently do not preserve the original effective type of the destinati= on > (or the effective type used to access the source) when doing this. With > some tricks we could (we also lose aligment guarantees of the original > accesses). >=20 > > Martin > >=20 > >=20 > > Add the following definition after 3.5, paragraph 2: > >=20 > > byte array > > object having either no declared type or an array of objects declared w= ith a byte type > >=20 > > byte type > > non-atomic character type This essentially becomes the "alias anything" type. > >=20 > > Modify 6.5,paragraph 6: > > The effective type of an object that is not a byte array, for an access= to its > > stored value, is the declared type of the object.97) If a value is > > stored into a byte array through an lvalue having a byte type, then > > the type of the lvalue becomes the effective type of the object for tha= t > > access and for subsequent accesses that do not modify the stored value. > > If a value is copied into a byte array using memcpy or memmove, or is > > copied as an array of byte type, then the effective type of the > > modified object for that access and for subsequent accesses that do not > > modify the value is the effective type of the object from which the > > value is copied, if it has one. For all other accesses to a byte array, > > the effective type of the object is simply the type of the lvalue used > > for the access. >=20 > What's the purpose of this change? To me this reads more confusing and > complicated than what I find in the c23 draft from April last year. Note that C23 has been finalized. This change is proposed for the revision after c23.=20 >=20 > I'll note that GCC does not take advantage of "The effective type of an > object for an access to its stored value is the declard type of the objec= t", > instead it always relies on the type of the lvalue (treating non-atomic > character types specially, as well as treating all string ops like memcpy > or strcpy as using a character type for the access) and the effective typ= e > of the object for that access and for subsequent accesses that do not > modify the stored value always becomes that of the lvalue type used for > the access. Understood. >=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); Let's make it an explicit store for the moment (should not make a difference though): *(struct B*)x.buf =3D *b; > y =3D x; // (*) > } >=20 > What's the effective type of 'x' in the 'y =3D x' copy?=C2=A0 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=C2=A0 x with type struct X). 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. > With your new > wording, does 'B' transfer to x.buf with memcpy? =C2=A0 Yes, it would. At least this is the intention. Note that this would currently be undefined behavior because x.buf has a declared type. So this is main thing we want to change, i.e. making this defined. > What's the > frankenstein effective type of 'x' then? What's the effective type > of 'y' after the copy? Can an lvalue of type 'B' access y.buf? All good questions, but unfortunately not clear even in the current wording I think. Martin >=20 > Richard. >=20 > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3230.pdf > >=20 > >=20