MMIX: Correct handling of C23 (...) functions, PR117618

This commit fixes a MMIX C23 (...)-handling bug; failing
gcc.dg/c23-stdarg-[46789].c execution tests.   But, this
isn't about a missing "|| arg.type != NULL_TREE" in the
PORT_setup_incoming_varargs function like most other
PR114175 port bugs exposed by the gcc.dg/c23-stdarg-6.c
.. -9.c tests; the MMIX port passes struct-return-values in
a register.  But, the bug is somewhat similar.

This bug seems like it was added already in
r13-3549-g4fe34cdcc80ac2, by incorrectly handling
TYPE_NO_NAMED_ARGS_STDARG_P-functions ((...)-functions);
counting them as having one parameter instead of none.  That
"+ 1" below is a kind-of hidden function_arg_advance call,
which shouldn't happen for (...)-functions.

	PR target/117618
	* config/mmix/mmix.cc (mmix_setup_incoming_varargs):
	Correct handling of C23 (...)-functions.
This commit is contained in:
Hans-Peter Nilsson 2024-12-29 08:14:14 +01:00
parent 83e291014f
commit 8a4e57e6bc

View file

@ -990,10 +990,18 @@ mmix_setup_incoming_varargs (cumulative_args_t args_so_farp_v,
{
CUMULATIVE_ARGS *args_so_farp = get_cumulative_args (args_so_farp_v);
/* The last named variable has been handled, but
args_so_farp has not been advanced for it. */
if (args_so_farp->regs + 1 < MMIX_MAX_ARGS_IN_REGS)
*pretend_sizep = (MMIX_MAX_ARGS_IN_REGS - (args_so_farp->regs + 1)) * 8;
/* Better pay special attention to (...) functions and not fold that
case into the general case in the else-arm. */
if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)))
{
*pretend_sizep = MMIX_MAX_ARGS_IN_REGS * 8;
gcc_assert (args_so_farp->regs == 0);
}
else
/* The last named variable has been handled, but
args_so_farp has not been advanced for it. */
if (args_so_farp->regs + 1 < MMIX_MAX_ARGS_IN_REGS)
*pretend_sizep = (MMIX_MAX_ARGS_IN_REGS - (args_so_farp->regs + 1)) * 8;
/* We assume that one argument takes up one register here. That should
be true until we start messing with multi-reg parameters. */