On 4/6/22 15:45, Marek Polacek via Gcc-patches wrote:
On Wed, Apr 06, 2022 at 04:36:49PM -0300, Alexandre Oliva via Gcc-patches wrote:On targets that return this from cdtors, cxx_eval_call_expression may flag flowing off the end of a dtor. That's preempted for ctors, and avoided entirely when dtors return void, but when they return this, the return value should be conceptually disregarded, without making room for such internal ABI details to make a program ill-formed, as in g++.dg/cpp2a/constexpr-dtor12.C on arm-eabi. Regstrapped on x86_64-linux-gnu, also verified the testcase fix on arm-eabi. Ok to install? for gcc/cp/ChangeLog * constexpr.cc (cxx_eval_call_expression): Disregard dtor result. --- gcc/cp/constexpr.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc index 9c40b0515747d..d8bc864ae6bcc 100644 --- a/gcc/cp/constexpr.cc +++ b/gcc/cp/constexpr.cc @@ -2889,7 +2889,8 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t, else { result = *ctx->global->values.get (res); - if (result == NULL_TREE && !*non_constant_p) + if (result == NULL_TREE && !*non_constant_p + && !DECL_DESTRUCTOR_P (fun))Would it make sense to use && !(DECL_DESTRUCTOR_P (fun) && targetm.cxx.cdtor_returns_this ()) instead?
I don't think that's necessary; it's the destructorness that makes it OK. And if it doesn't return this we would have taken the VOID_TYPE_P branch before.
Jason
