public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/109745] [13/14 Regression] Incorrect code generated with -O1 when having a constexpr object modifying a mutable member Date: Thu, 11 May 2023 20:31:50 +0000 [thread overview] Message-ID: <bug-109745-4-NE4S6o8ANi@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-109745-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745 --- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:02777f20be4f40160f1b4ed34fa59ba75245b5b7 commit r14-742-g02777f20be4f40160f1b4ed34fa59ba75245b5b7 Author: Patrick Palka <ppalka@redhat.com> Date: Thu May 11 16:31:33 2023 -0400 c++: 'mutable' subobject of constexpr variable [PR109745] r13-2701-g7107ea6fb933f1 made us correctly accept during constexpr evaluation 'mutable' member accesses of objects constructed during that evaluation, while continuing to reject such accesses for constexpr objects constructed outside of that evaluation, by considering the CONSTRUCTOR_MUTABLE_POISON flag during cxx_eval_component_reference. However, this flag is set only for the outermost CONSTRUCTOR of a constexpr variable initializer, so if we're accessing a 'mutable' member of a nested CONSTRUCTOR, the flag won't be set and we won't reject the access. This can lead to us accepting invalid code, as in the first testcase, or even wrong code generation due to our speculative constexpr evaluation, as in the second and third testcase. This patch fixes this by setting CONSTRUCTOR_MUTABLE_POISON recursively rather than only on the outermost CONSTRUCTOR. PR c++/109745 gcc/cp/ChangeLog: * typeck2.cc (poison_mutable_constructors): Define. (store_init_value): Use it instead of setting CONSTRUCTOR_MUTABLE_POISON directly. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-mutable4.C: New test. * g++.dg/cpp0x/constexpr-mutable5.C: New test. * g++.dg/cpp1y/constexpr-mutable2.C: New test.
next prev parent reply other threads:[~2023-05-11 20:31 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-05 9:50 [Bug c++/109745] New: " carlosgalvezp at gmail dot com 2023-05-05 9:52 ` [Bug c++/109745] " carlosgalvezp at gmail dot com 2023-05-05 11:56 ` albin at yahoo dot com 2023-05-05 15:04 ` [Bug c++/109745] [13/14 Regression] " mpolacek at gcc dot gnu.org 2023-05-11 15:01 ` ppalka at gcc dot gnu.org 2023-05-11 20:31 ` cvs-commit at gcc dot gnu.org [this message] 2023-05-11 20:32 ` [Bug c++/109745] [13 " ppalka at gcc dot gnu.org 2023-05-12 15:08 ` cvs-commit at gcc dot gnu.org 2023-05-12 15:22 ` ppalka at gcc dot gnu.org 2023-05-12 21:17 ` carlosgalvezp at gmail dot com
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-109745-4-NE4S6o8ANi@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).