https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97790
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:fc531c2ed3ce456efca946e995544b216b3c16df commit r11-4936-gfc531c2ed3ce456efca946e995544b216b3c16df Author: Jakub Jelinek <ja...@redhat.com> Date: Thu Nov 12 10:46:04 2020 +0100 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 <ja...@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.
