c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling [PR97790]

As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR too)
suffer from the same problem that I was trying to fix in
r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f
for CLEANUP_STMT, namely that if in the middle of the body expression of
those stmts is e.g. return stmt, goto, break or continue (something that
changes *jump_target and makes it start skipping stmts), we then skip the
cleanups too, which is not appropriate - the cleanups were either queued up
during the non-skipping execution of the body (for CLEANUP_POINT_EXPR), or
for TRY_FINALLY_EXPR are relevant already after entering the body block.

> Would it make sense to always use a NULL jump_target when evaluating
> cleanups?

I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that
during constexpr evaluation the cleanups will most often be just very simple
destructor calls (or calls to cleanup attribute functions).
Furthermore, for neither of these 3 tree codes we'll reach that code if
jump_target && *jump_target initially (there is a return NULL_TREE much
earlier for those except for trees that could embed labels etc. in it and
clearly these 3 don't count in that).

2020-11-12  Jakub Jelinek  <jakub@redhat.com>

	PR c++/97790
	* constexpr.c (cxx_eval_constant_expression) <case CLEANUP_POINT_EXPR,
	case TRY_FINALLY_EXPR, case CLEANUP_STMT>: Don't pass jump_target to
	cxx_eval_constant_expression when evaluating the cleanups.

	* g++.dg/cpp2a/constexpr-dtor9.C: New test.

0 files changed, 0 insertions, 0 deletions