From: Martin Uecker <uecker@tugraz.at>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: Re: aliasing
Date: Mon, 18 Mar 2024 12:56:52 +0100 [thread overview]
Message-ID: <fe95afae9b222777447db58c7d83f13f5c1fdc55.camel@tugraz.at> (raw)
In-Reply-To: <80d108c853404b7f1e48bf001db37d94e6651f42.camel@tugraz.at>
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 AM Martin Uecker <uecker@tugraz.at> 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 = *b;
>
> > y = x; // (*)
> > }
> >
> > What's the effective type of 'x' in the 'y = 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:
— a type compatible with the effective type of the object,
...
— 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
— a character type."
... and we would need to move "a character type" above
in the list to make it defined.
Martin
next prev parent reply other threads:[~2024-03-18 11:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 7:03 aliasing Martin Uecker
2024-03-18 8:26 ` aliasing Richard Biener
2024-03-18 10:55 ` aliasing Martin Uecker
2024-03-18 11:56 ` Martin Uecker [this message]
2024-03-18 13:21 ` aliasing Richard Biener
2024-03-18 15:13 ` aliasing Martin Uecker
2024-03-18 9:00 ` aliasing David Brown
2024-03-18 10:09 ` aliasing Jonathan Wakely
2024-03-18 11:41 ` aliasing Martin Uecker
2024-03-18 13:29 ` aliasing David Brown
2024-03-18 13:54 ` aliasing Andreas Schwab
2024-03-18 16:46 ` aliasing David Brown
2024-03-18 16:55 ` aliasing David Brown
2024-03-18 15:00 ` aliasing Martin Uecker
2024-03-18 17:11 ` aliasing David Brown
-- strict thread matches above, loose matches on Subject: below --
1999-08-21 9:23 aliasing Jason Moxham
1999-08-21 9:46 ` aliasing Mark Mitchell
1999-08-31 23:20 ` aliasing Mark Mitchell
1999-08-31 23:20 ` aliasing Jason Moxham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fe95afae9b222777447db58c7d83f13f5c1fdc55.camel@tugraz.at \
--to=uecker@tugraz.at \
--cc=gcc@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).