From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 7DF96385840A for ; Mon, 18 Mar 2024 13:22:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7DF96385840A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7DF96385840A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710768130; cv=none; b=ZUT5Mfg6SAEtNlFI4wxY+p2qGAvNMz1yDrS2zaJ/2l6a/21sNxa7dKDm3cx79dO0Jh6lENOsBfoXsON80IE4duzLnaX2UVInopK9unNofDiUBnrv5qsLZ54XtYBhHFNbJopW1gLKNdQlUr603qqN/NEHAgic3CYlIygmF6Q3Rjk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710768130; c=relaxed/simple; bh=53jKD+GawBAFHzfHo3KvizmgPzmTq8mElOZMasbSGA0=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=aLc99GBwioMocZpcQGgeB69bSVfTTNfQiAGV8TfqhXdr1LLU7HlH6VHWq3B0VDxRkP73qjGe1CX5I+FzmFF2luoo5hG2DKBqBxPsqj+23AKFCLJnZ1h8psob5E5+1g2TSvaJEWQhMeMlGFU8lh1GSXkrz84+rDsH2oQO+hvokG0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-513d247e3c4so3546481e87.0 for ; Mon, 18 Mar 2024 06:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710768124; x=1711372924; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Q19FuJ+eqvsSD7ZR5UUmnhazY+SJm9KGqKqD6Mc+1G4=; b=RPU67XeLIQjo5ejVLAvZSQ6urPZVle7UTeTLv4pfSc37Z9A4ceEcLygkyetd3jTxzp f9ZcMAvVOv08qzV7Vb0LNKMlD58zUKG8DmSze07ancfH6rhDsPbW9cGMpLmDWDpgAqFC Du9L7SK/cbi47gJ/XC4zUNW6RmpoGkDr/GH4cj2b9ADO5ZCef8rXEuuvS0Bl8aysNp4I pgtbF1SB6CVoCwiQMs5BRO6HSFUrx1j0w625+ZJUGFxaYYQ41/IYxmdjjoX5gXfOSQEg D0V6v+Imxqp/jCh4J3iZ0bVEvR+GaeRKwPZxUKykd4hrfAbONsBcISmrznXPCQoc4gjI 5X+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710768124; x=1711372924; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Q19FuJ+eqvsSD7ZR5UUmnhazY+SJm9KGqKqD6Mc+1G4=; b=Jx8OZsZc8BPuv95jGJkkVCf6cNJOZ6k1Wyupw69HbeEdL2wIBrsbQBQDb9KEgyvl/r h99XMnBsTV/8nghTgYDvtFnu8tvyr/qkRxJ3R51opl+dtfS/l3T6AjeRfHA3G+/8lGfU foTaQuwpbs2GfO0QCvjmXLiO0wvz17ylH89mMbjdhQBoy8ITZ6lnv+RCOMjw7Cj35BN/ qUDLWMeDmFSRRMiIpyelBB9KWAzhLia9XW8zTXvV9cDlsUzWDQLtXfVyY+eyOU0GUVEH Wz2YS1+1c7DLP3Oter3Z9xM/+juZP7shKe312LXwV3qKo5ZajzbxigMvp2BmaGpaGlxK pYLw== X-Gm-Message-State: AOJu0Yw7/0zGlsX+ukXTqdMwQ8cmj4XtGY1obzVH667F4hNv2L8pvqp9 61s+2Kp5woSj/M/9aFAEmVCseFb7jBiw2bYtpAPh33zCkQFjRb7KX6J+WBzxNIron8yYqSu9iuP Jj36zq1mPU4+Pi9zvmfSaQufsnEL3q02RAQg= X-Google-Smtp-Source: AGHT+IHj3+/Z/LwoSLB0cwpxvsGypGXlnoqOaTaSLjbyPbNHeLJhWYsqP8BHZeaYOqEdV136DOmqx9sCFgVoUVA8wJ8= X-Received: by 2002:a19:3802:0:b0:513:ce92:e264 with SMTP id f2-20020a193802000000b00513ce92e264mr4491458lfa.0.1710768124330; Mon, 18 Mar 2024 06:22:04 -0700 (PDT) MIME-Version: 1.0 References: <80d108c853404b7f1e48bf001db37d94e6651f42.camel@tugraz.at> In-Reply-To: From: Richard Biener Date: Mon, 18 Mar 2024 14:21:52 +0100 Message-ID: Subject: Re: aliasing To: Martin Uecker Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: On Mon, Mar 18, 2024 at 12:56=E2=80=AFPM Martin Uecker w= rote: > > 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: > > > > > > > > > > > Let me give you an complication example made valid in C++: > > > > > > struct B { float x; float y; }; > > > struct X { int n; char buf[8]; } x, y; > > > > > > 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; // (*) > > > } > > > > > > What's the effective type of 'x' in the 'y =3D x' copy? > > > > 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). > > > > 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. > > Actually, I think this is not allowed because: > > "An object shall have its stored value accessed only by an > lvalue expression that has one of the following types: > > =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 > > =E2=80=94 a character type." > > ... and we would need to move "a character type" above > in the list to make it defined. So after *(struct B*)x.buf =3D *b; 'x' cannot be used to access itself? In particular also an access to 'x.n' is affected by this? 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 ... 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? 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? Richard. > Martin > >