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))
;
R.
