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++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256 Date: Sat, 19 Feb 2022 08:03:03 +0000 [thread overview] Message-ID: <bug-104513-4-E1bOMm8886@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-104513-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104513 --- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-11 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:14f79acb6214108ce8e44a767e7eeabb456440fe commit r11-9605-g14f79acb6214108ce8e44a767e7eeabb456440fe Author: Jakub Jelinek <jakub@redhat.com> Date: Mon Feb 14 16:56:15 2022 +0100 c++: Don't reject GOTO_EXPRs to cdtor_label in potential_constant_expression_1 [PR104513] return in ctors on targetm.cxx.cdtor_returns_this () target like arm is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits RETURN_EXPR with the this. Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this () a return is emitted similarly. potential_constant_expression_1 was rejecting these gotos and so we incorrectly rejected these testcases, but actual cxx_eval* is apparently handling these just fine. I was a little bit worried that for the destruction of bases we wouldn't evaluate something we should, but as the testcase shows, that is evaluated through try ... finally and there is nothing after the cdtor_label. For arm there is RETURN_EXPR this; but we don't really care about the return value from ctors and dtors during the constexpr evaluation. I must say I don't see much the point of cdtor_labels at all, I'd think that with try ... finally around it for non-arm we could just RETURN_EXPR instead of the GOTO_EXPR and the try/finally gimplification would DTRT, and we could just add the right return value for the arm case. 2022-02-14 Jakub Jelinek <jakub@redhat.com> PR c++/104513 * constexpr.c (potential_constant_expression_1) <case GOTO_EXPR>: Don't punt if returns (target). * g++.dg/cpp1y/constexpr-104513.C: New test. * g++.dg/cpp2a/constexpr-dtor12.C: New test. (cherry picked from commit 02a981a8e512934a990d1427d14e8e884409fade)
next prev parent reply other threads:[~2022-02-19 8:03 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-12 11:14 [Bug c++/104513] New: " jakub at gcc dot gnu.org 2022-02-12 11:15 ` [Bug c++/104513] " jakub at gcc dot gnu.org 2022-02-12 12:53 ` jakub at gcc dot gnu.org 2022-02-12 18:12 ` jakub at gcc dot gnu.org 2022-02-14 15:57 ` cvs-commit at gcc dot gnu.org 2022-02-14 15:57 ` jakub at gcc dot gnu.org 2022-02-19 8:03 ` cvs-commit at gcc dot gnu.org [this message] 2022-05-10 8:23 ` cvs-commit at gcc dot gnu.org 2022-05-11 6:24 ` cvs-commit 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-104513-4-E1bOMm8886@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).