]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++: Don't reject GOTO_EXPRs to cdtor_label in potential_constant_expression_1 [PR104513]
authorJakub Jelinek <jakub@redhat.com>
Mon, 14 Feb 2022 15:56:15 +0000 (16:56 +0100)
committerJakub Jelinek <jakub@redhat.com>
Wed, 11 May 2022 05:58:40 +0000 (07:58 +0200)
commit87cd4bc02f602226922e6c8099a2f4687664bed9
tree5ae73a24cd954ec8774d2c665e8293c6823f4f13
parent77ee9b906d1c214648230d417b45831b8ef8386a
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.

(cherry picked from commit 02a981a8e512934a990d1427d14e8e884409fade)
gcc/cp/constexpr.c
gcc/testsuite/g++.dg/cpp1y/constexpr-104513.C [new file with mode: 0644]