On Nov 19, 2023, Alexandre Oliva <ol...@adacore.com> wrote:
> On arm-eabi targets, c23 stdarg execution tests that pass arguments to
> (...) functions (without any named argument), the caller passes
> everything on the stack, but the callee expects arguments in
> registers.
Ping? This slightly modified patch only adds comments to
aapcs_layout_arg compared with the original one.
The commit message doesn't name explicitly the fixed testsuite
failures. Here they are:
FAIL: gcc.dg/c23-stdarg-4.c execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O0 execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O1 execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O2 execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -O3 -g execution test
FAIL: gcc.dg/torture/c23-stdarg-split-1a.c -Os execution test
Tested on arm-eabi. Ok to install?
arm: fix c23 0-named-args caller-side stdarg
On arm-eabi targets, c23 stdarg execution tests that pass arguments to
(...) functions (without any named argument), the caller passes
everything on the stack, but the callee expects arguments in
registers. My reading of the AAPCS32 suggests that the caller is
correct, so I've arranged for the caller to pass the first arguments
in registers to TYPE_NO_NAMED_STDARG_P-typed functions.
The implementation issue in calls.cc is that n_named_args is initially
set to zero in expand_call, so the test argpos < n_named_args yields
false for all arguments, and aapcs_layout_arg takes !named as meaning
stack.
But there's a catch there: on targets in which neither
strict_argument_naming nor !pretend_outgoing_varargs_named hold,
n_named_args is bumped up to num_actuals, which covers stdarg
arguments in pre-c23 cases, but not for TYPE_NO_NAMED_ARGS_STDARG_P.
I'm hesitant to modify the generic ABI-affecting code, so I'm going
for a more surgical fix for ARM AAPCS only. I suspect we might want
yet another targetm predicate to enable the n_named_args overriding
block to disregard TYPE_NO_NAMED_ARGS_STDARG_P, and allow all actuals
to be passed as if named.
for gcc/ChangeLog
* config/arm/arm.h (CUMULATIVE_ARGS): Add aapcs_pretend_named.
* config/arm/arm.cc (arm_init_cumulative_args): Set it for
aapcs no-named-args stdarg functions.
(aapcs_layout_arg): Ignore named if aapcs_pretend_named.
---
gcc/config/arm/arm.cc | 9 +++++++--
gcc/config/arm/arm.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 6e3e2e8fb1bfb..4a350bd8c8f47 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -7019,8 +7019,11 @@ aapcs_layout_arg (CUMULATIVE_ARGS *pcum, machine_mode
mode,
pcum->aapcs_arg_processed = true;
/* Special case: if named is false then we are handling an incoming
- anonymous argument which is on the stack. */
- if (!named)
+ anonymous argument which is on the stack, unless
+ aapcs_pretend_named, in which case we're dealing with a
+ TYPE_NO_NAMED_ARGS_STDARG_P call and, even if args are !named, we
+ ought to use available registers first. */
+ if (!named && !pcum->aapcs_pretend_named)
return;
/* Is this a potential co-processor register candidate? */
@@ -7141,6 +7144,8 @@ arm_init_cumulative_args (CUMULATIVE_ARGS *pcum, tree
fntype,
pcum->aapcs_arg_processed = false;
pcum->aapcs_cprc_slot = -1;
pcum->can_split = true;
+ pcum->aapcs_pretend_named = (fntype
+ && TYPE_NO_NAMED_ARGS_STDARG_P (fntype));
if (pcum->pcs_variant != ARM_PCS_AAPCS)
{
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index a9c2752c0ea5e..65d2d567686d3 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1702,6 +1702,7 @@ typedef struct
unsigned aapcs_vfp_reg_alloc;
int aapcs_vfp_rcount;
MACHMODE aapcs_vfp_rmode;
+ bool aapcs_pretend_named; /* Set for TYPE_NO_NAMED_ARGS_STDARG_P. */
} CUMULATIVE_ARGS;
#endif
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive
