[PATCH] c++: ICE with NSDMIs and fn arguments [PR116015]

[Jason Merrill]

On 8/9/24 4:21 PM, Marek Polacek wrote:
> On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote:
>> On 8/8/24 1:37 PM, Marek Polacek wrote:
>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>>>
>>> -- >8 --
>>> The problem in this PR is that we ended up with
>>>
>>>     {.rows=(&<PLACEHOLDER_EXPR struct Widget>)->n,
>>>      .outer_stride=(&<PLACEHOLDER_EXPR struct MatrixLayout>)->rows}
>>>
>>> that is, two PLACEHOLDER_EXPRs for different types on the same level
>>> in one { }.  That should not happen; we may, for instance, neglect to
>>> replace a PLACEHOLDER_EXPR due to CONSTRUCTOR_PLACEHOLDER_BOUNDARY on
>>> the constructor.
>>>
>>> The same problem happened in PR100252, which I fixed by introducing
>>> replace_placeholders_for_class_temp_r.  That didn't work here, though,
>>> because r_p_for_c_t_r only works for non-eliding TARGET_EXPRs: replacing
>>> a PLACEHOLDER_EXPR with a temporary that is going to be elided will
>>> result in a crash in gimplify_var_or_parm_decl when it encounters such
>>> a loose decl.
>>>
>>> But leaving the PLACEHOLDER_EXPRs in is also bad because then we end
>>> up with this PR.
>>>
>>> TARGET_EXPRs for function arguments are elided in gimplify_arg.  The
>>> argument will get a real temporary only in get_formal_tmp_var.  One
>>> idea was to use the temporary that is going to be elided anyway, and
>>> then replace_decl it with the real object once we get it.  But that
>>> didn't work out: one problem is that we elide the TARGET_EXPR for an
>>> argument before we create the real temporary for the argument, and
>>> when we get it, the context that this was a TARGET_EXPR for an argument
>>> has been lost.  We're also in the middle end territory now, even though
>>> this is a C++-specific problem.
>>
>> How complex!
>>
>>> I figured that since the to-be-elided temporary is going to stay around
>>> until gimplification, the front end is free to use it.  Once we're done
>>> with things like store_init_value, which replaces PLACEHOLDER_EXPRs with
>>> the decl it is initializing, we can turn those to-be-elided temporaries
>>> into PLACEHOLDER_EXPRs again, so that cp_gimplify_init_expr can replace
>>> them with the real object once available.  The context is not lost so we
>>> do not need an extra flag for these makeshift temporaries.
>>
>> Clever, that makes a lot of sense.  But I wonder if we can avoid the problem
>> more simply than working around it?
>>
>> I see that the get_formal_tmp_var happens directly from gimplify_arg, so it
>> strips the TARGET_EXPR to avoid a temporary...and then immediately turns
>> around and creates a new temporary.
>>
>> Would it work to stop stripping the TARGET_EXPR in gimplify_arg and
>> therefore stop setting TARGET_EXPR_ELIDING_P in convert_for_arg_passing?
> 
> Well, it does fix the ICE.  But then a number of testcases fail :(.
> For instance, pr23372.C.  .gimple diff w/ and w/o stripping the TARGET_EXPR:
> 
> @@ -1,6 +1,9 @@
>   void g (struct A * a)
>   {
> -  f (MEM[(const struct A &)a]);
> +  struct A D.2829;
> +
> +  D.2829 = MEM[(const struct A &)a];
> +  f (D.2829);
>   }
> 
> The extra copy is there even in .optimized with -O2.
> 
> 
> It's always sad when we have to add complicated code just to work around
> a corner case, but the above pessimization looks pretty important :(.

Ah, good point.  In that case, the stripping avoids the copy because the 
TARGET_EXPR_INITIAL is already (adjustable into) a suitable lvalue.  The 
current code already fails to avoid the redundant copy when _INITIAL is 
a CONSTRUCTOR:

void g (struct A * a)
{
   struct A D.2805;

   D.2805 = {}; // boo
   f (D.2805);
}

I'm failing to find the PR about this issue.

How about the change I mentioned only in the CONSTRUCTOR case?

Jason