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.
next prev 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: linkBe 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).