On 4/7/22 18:25, Alexandre Oliva wrote:
Hello, Jason,
On Apr 6, 2022, Jason Merrill <ja...@redhat.com> wrote:
On 4/6/22 15:36, Alexandre Oliva wrote:
Please adjust your patch subject lines for the new guidelines adopted
as part of the git transition:
https://gcc.gnu.org/contribute.html#patches
Oh, wow, I had missed those guidelines entirely! *blush*
Thanks for the pointer. I'm taking note of it for future submissions.
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.
Is there a PR for this issue?
I'm afraid not, it's just one of many testsuite fails that I've been
working on cleaning up.
The patch looks fine, but why doesn't the implicit return 'this' on
arm-eabi already make the result non-null?
That's a good question that I didn't have an answer for.
It's the explicit 'return' statement in T::~T(), turned into a goto,
that interrupts the iteration over the stmt list containing the return
stmt:
<<< Unknown tree: must_not_throw_expr
{
<<< Unknown tree: cleanup_stmt
<<< Unknown tree: cleanup_stmt
<<cleanup_point <<< Unknown tree: expr_stmt
(void) (((struct T *) this)->D.4458.s = (TARGET_EXPR <D.4487,
operato\
r new (4)>;, TARGET_EXPR <D.4488, 1>;, *(int *) D.4487 = NON_LVALUE_EXPR <42>;,\
D.4488 = 0;;, (int *) D.4487;)) >>>>>;
// predicted unlikely by goto predictor.;
goto <D.4489>;
(void) S::~S (&((struct T *) this)->D.4458)
>>>;
*(struct T *) this = {CLOBBER}
>>>;
} (*)
<D.4489>:;
return this;
>>>
(*) eval'ing this block sets jump_target to <D.4489>, which satisfies
the returns(tree*) predicate, so cxx_eval_statement_list bails.
Now, ISTM that the goto target selected for the return stmt bypasses the
subobject dtor call and the full-object clobber. That sounds like
another bug, no?
The subobject cleanup and clobber should be evaluated along the way, the
evaluation of CLEANUP_EXPR isn't affected by jump_target.
I think the only thing we're wrongly skipping is the actual return, and
your patch works around that. I think that makes sense for now; I have
a patch for GCC 13 to remove cdtor_label entirely.
Your patch is OK.
Jason
