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.

diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc
index ce014387e614597a57a897ac06f582ace773f54b..39725c96991bdd31a809a798443507cc26748fca 100644 (file)
--- a/gcc/config/mmix/mmix.cc
+++ b/gcc/config/mmix/mmix.cc
@@ -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.  */