https://gcc.gnu.org/g:8a4e57e6bc63eba78e5f3b0090e58d48a95dcbc7
commit r15-6463-g8a4e57e6bc63eba78e5f3b0090e58d48a95dcbc7
Author: Hans-Peter Nilsson <h...@bitrange.com>
Date: Sun Dec 29 08:14:14 2024 +0100
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:
---
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..39725c96991b 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. */
