public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: gcc-patches@gcc.gnu.org
Cc: Joseph Myers <joseph@codesourcery.com>,
	Nick Clifton <nickc@redhat.com>,
	Richard Earnshaw <richard.earnshaw@arm.com>,
	Ramana Radhakrishnan <ramana.gcc@gmail.com>,
	Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Subject: Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg
Date: Tue, 05 Dec 2023 23:27:49 -0300	[thread overview]
Message-ID: <ora5qorroa.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <orleauryfh.fsf@lxoliva.fsfla.org> (Alexandre Oliva's message of "Sun, 19 Nov 2023 04:32:02 -0300")

On Nov 19, 2023, Alexandre Oliva <oliva@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

  reply	other threads:[~2023-12-06  2:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-19  7:32 Alexandre Oliva
2023-12-06  2:27 ` Alexandre Oliva [this message]
2024-01-23  8:26   ` Alexandre Oliva
2024-02-26 16:41     ` Matthew Malcomson
2024-03-01  4:38       ` Alexandre Oliva
2024-03-01 14:56         ` Richard Earnshaw (lists)
2024-03-06 20:28           ` Alexandre Oliva
2024-03-06 20:32             ` Jakub Jelinek
2024-03-07 10:01             ` Richard Earnshaw (lists)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ora5qorroa.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=kyrylo.tkachov@arm.com \
    --cc=nickc@redhat.com \
    --cc=ramana.gcc@gmail.com \
    --cc=richard.earnshaw@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).