public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/84414] miscompile due to assuming that object returned by value cannot alias its own member pointer values
Date: Tue, 20 Feb 2024 12:55:45 +0000	[thread overview]
Message-ID: <bug-84414-4-nH9BYws1KI@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-84414-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84414

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Smith from comment #2)
> In fact, I think the *only* problem here is that the above rule does not
> allow the caller and the callee to observe the objects having the same
> address.

Would it be fair to argue that the A::children pointer storing the address of
the temporary becomes an invalid pointer value as soon as the temporary is
destroyed, and then it's not valid to use that invalid pointer value. Testing
`a.children == &a` has an unspecified (at best?) result, so you can't actually
detect whether a temporary was created or not. You can observe that the
arbitrary bit pattern of an invalid pointer value happens to equal &a but that
bit pattern could have magically morphed when it became invalid (because the
implementation tracks pointer provenance and intentionally messes with pointer
values when they become invalid just to screw with you).

Inside Bar using a.children[i] is using the invalid pointer value that points
to an out-of-scope temporary, which is UB. Attempting to observe whether
a.children == &a also uses that invalid pointer value and has an unspecified
result.

> I'll take this to the committee and see whether we can get that rule relaxed
> slightly.

I see you sent the email with subject "on implicit object copies in function
return and alias analysis" and nobody replied. I don't think it ever made it to
the issues list either.

I'll repeat the above argument there.

  parent reply	other threads:[~2024-02-20 12:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-84414-4@http.gcc.gnu.org/bugzilla/>
2021-12-17  3:17 ` pinskia at gcc dot gnu.org
2021-12-17  3:17 ` pinskia at gcc dot gnu.org
2023-11-03  8:24 ` rguenth at gcc dot gnu.org
2024-02-20 12:55 ` redi at gcc dot gnu.org [this message]
2024-03-01 17:19 ` redi at gcc dot gnu.org

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=bug-84414-4-nH9BYws1KI@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).