[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue May 10 08:23:58 GMT 2022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104513
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:48ec754a6e157b47ea9bb1c43b0fabab511dbe65
commit r10-10680-g48ec754a6e157b47ea9bb1c43b0fabab511dbe65
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)
More information about the Gcc-bugs
mailing list