diff options
| author | Hans-Peter Nilsson <hp@bitrange.com> | 2024-12-29 08:14:14 +0100 |
|---|---|---|
| committer | Hans-Peter Nilsson <hp@bitrange.com> | 2024-12-30 04:02:48 +0100 |
| commit | 8a4e57e6bc63eba78e5f3b0090e58d48a95dcbc7 (patch) | |
| tree | 5611fa4c9138ee59fe2a31a5a714d5325fb7b047 | |
| parent | 83e291014fff0b3ce1baedf59292390726d67335 (diff) | |
| download | gcc-8a4e57e6bc63eba78e5f3b0090e58d48a95dcbc7.zip gcc-8a4e57e6bc63eba78e5f3b0090e58d48a95dcbc7.tar.gz gcc-8a4e57e6bc63eba78e5f3b0090e58d48a95dcbc7.tar.bz2 | |
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.
| -rw-r--r-- | gcc/config/mmix/mmix.cc | 16 |
1 files changed, 12 insertions, 4 deletions
diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc index ce01438..39725c9 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. */ |