On Fri, Mar 01, 2024 at 01:53:08PM +0000, Richard Earnshaw (lists) wrote:
> On 29/02/2024 17:56, Jakub Jelinek wrote:
> > On Thu, Feb 29, 2024 at 05:51:03PM +0000, Richard Earnshaw (lists) wrote:
> >> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we
> >> never reach the point where you pick zero. So perhaps I'm worrying about
> >> nothing.
> >
> > If you are worried about the
> > + else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype)
> > + && ! targetm.calls.pretend_outgoing_varargs_named (args_so_far))
> > n_named_args = 0;
> > case in the patch, we know at that point that the initial n_named_args is
> > equal to structure_value_addr_parm, so either 0, in that case
> > --n_named_args;
> > would yield the undesirable negative value, so we want 0 instead; for that
> > case we could as well just have ; in there instead of n_named_args = 0;,
> > or it is 1, in that case --n_named_args; would turn that into 0.
> >
> > Jakub
> >
>
> No, I was thinking about the case of strict_argument_naming when the first
> argument is the artificial return value pointer. In that case we'd want
> n_named_args=1.
>
> But I think it's a non-issue as that will be caught by
>
> if ((type_arg_types != 0 || TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
> && targetm.calls.strict_argument_naming (args_so_far))
> ;
Yes, that for strict argument naming and calls to
struct large_struct foo (...);
with the patch we set n_named_args = 1 early:
else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
n_named_args = structure_value_addr_parm;
and then
if ((type_arg_types != 0 || TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
&& targetm.calls.strict_argument_naming (args_so_far))
;
doesn't change it.
Jakub
