fc531c2ed3
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.
32 lines
347 B
C
32 lines
347 B
C
// PR c++/97790
|
|
// { dg-do compile { target c++20 } }
|
|
|
|
struct S
|
|
{
|
|
int *d;
|
|
int n;
|
|
constexpr S () : d(new int[1]{}), n(1) {}
|
|
constexpr ~S () { delete [] d; }
|
|
};
|
|
|
|
constexpr S
|
|
foo ()
|
|
{
|
|
return S ();
|
|
}
|
|
|
|
constexpr int
|
|
bar ()
|
|
{
|
|
return foo ().n;
|
|
}
|
|
|
|
constexpr int
|
|
baz ()
|
|
{
|
|
return S ().n;
|
|
}
|
|
|
|
constexpr int a = baz ();
|
|
constexpr int b = bar ();
|