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.
---
 gcc/config/mmix/mmix.cc | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc
index ce014387e614..326535f11a97 100644
--- 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.  */
-- 
2.39.2

Reply via email to