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.