public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: <gcc-patches@gcc.gnu.org>,  <Kyrylo.Tkachov@arm.com>,
	 <richard.earnshaw@arm.com>
Subject: Re: [PATCH 06/11] aarch64: Fix pac-ret eh_return tests
Date: Tue, 05 Sep 2023 15:56:36 +0100	[thread overview]
Message-ID: <mptledksm6z.fsf@arm.com> (raw)
In-Reply-To: <c9a619fcadf6e05dda1b92e83da0eb91cffb12a2.1692699125.git.szabolcs.nagy@arm.com> (Szabolcs Nagy's message of "Tue, 22 Aug 2023 11:38:49 +0100")

Szabolcs Nagy <szabolcs.nagy@arm.com> writes:
> This is needed since eh_return no longer prevents pac-ret in the
> normal return path.
>
> gcc/testsuite/ChangeLog:
>
> 	* gcc.target/aarch64/return_address_sign_1.c: Move func4 to ...
> 	* gcc.target/aarch64/return_address_sign_2.c: ... here and fix the
> 	scan asm check.
> 	* gcc.target/aarch64/return_address_sign_b_1.c: Move func4 to ...
> 	* gcc.target/aarch64/return_address_sign_b_2.c: ... here and fix the
> 	scan asm check.
> ---
>  .../gcc.target/aarch64/return_address_sign_1.c  | 13 +------------
>  .../gcc.target/aarch64/return_address_sign_2.c  | 17 +++++++++++++++--
>  .../aarch64/return_address_sign_b_1.c           | 11 -----------
>  .../aarch64/return_address_sign_b_2.c           | 17 +++++++++++++++--
>  4 files changed, 31 insertions(+), 27 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c b/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
> index 232ba67ade0..114a9dacb3f 100644
> --- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_1.c
> @@ -37,16 +37,5 @@ func3 (int a, int b, int c)
>    /* autiasp */
>  }
>  
> -/* eh_return.  */
> -void __attribute__ ((target ("arch=armv8.3-a")))
> -func4 (long offset, void *handler, int *ptr, int imm1, int imm2)
> -{
> -  /* no paciasp */
> -  *ptr = imm1 + foo (imm1) + imm2;
> -  __builtin_eh_return (offset, handler);
> -  /* no autiasp */
> -  return;
> -}
> -
> -/* { dg-final { scan-assembler-times "autiasp" 3 } } */
>  /* { dg-final { scan-assembler-times "paciasp" 3 } } */
> +/* { dg-final { scan-assembler-times "autiasp" 3 } } */

I suppose there is no normal return path here.  I don't know how quickly
we'd realise that though, in the sense that the flag register becomes known-1.
But a quick-and-dirty check would be whether the exit block has a single
predecessor, which in a function that calls eh_return should mean
that the eh_return is unconditional.

But that might not be worth worrying about, given the builtin's limited
use case.  And even if it is worth worrying about, keeping the test in
this file would mix correctness with optimisation, which isn't a good
thing for scan-assembler-times.

So yeah, I agree this is OK.  It should probably be part of 03 though,
so that no individual commit causes a regression.

Thanks,
Richard

> diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c b/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
> index a4bc5b45333..d93492c3c43 100644
> --- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_2.c
> @@ -14,5 +14,18 @@ func1 (int a, int b, int c)
>    /* retaa */
>  }
>  
> -/* { dg-final { scan-assembler-times "paciasp" 1 } } */
> -/* { dg-final { scan-assembler-times "retaa" 1 } } */
> +/* eh_return.  */
> +void __attribute__ ((target ("arch=armv8.3-a")))
> +func4 (long offset, void *handler, int *ptr, int imm1, int imm2)
> +{
> +  /* paciasp */
> +  *ptr = imm1 + foo (imm1) + imm2;
> +  if (handler)
> +    /* br */
> +    __builtin_eh_return (offset, handler);
> +  /* retaa */
> +  return;
> +}
> +
> +/* { dg-final { scan-assembler-times "paciasp" 2 } } */
> +/* { dg-final { scan-assembler-times "retaa" 2 } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_1.c b/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_1.c
> index 43e32ab6cb7..697fa30dc5a 100644
> --- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_1.c
> @@ -37,16 +37,5 @@ func3 (int a, int b, int c)
>    /* autibsp */
>  }
>  
> -/* eh_return.  */
> -void __attribute__ ((target ("arch=armv8.3-a")))
> -func4 (long offset, void *handler, int *ptr, int imm1, int imm2)
> -{
> -  /* no pacibsp */
> -  *ptr = imm1 + foo (imm1) + imm2;
> -  __builtin_eh_return (offset, handler);
> -  /* no autibsp */
> -  return;
> -}
> -
>  /* { dg-final { scan-assembler-times "pacibsp" 3 } } */
>  /* { dg-final { scan-assembler-times "autibsp" 3 } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_2.c b/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_2.c
> index 9ed64ce0591..748924c72f3 100644
> --- a/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/return_address_sign_b_2.c
> @@ -14,5 +14,18 @@ func1 (int a, int b, int c)
>    /* retab */
>  }
>  
> -/* { dg-final { scan-assembler-times "pacibsp" 1 } } */
> -/* { dg-final { scan-assembler-times "retab" 1 } } */
> +/* eh_return.  */
> +void __attribute__ ((target ("arch=armv8.3-a")))
> +func4 (long offset, void *handler, int *ptr, int imm1, int imm2)
> +{
> +  /* paciasp */
> +  *ptr = imm1 + foo (imm1) + imm2;
> +  if (handler)
> +    /* br */
> +    __builtin_eh_return (offset, handler);
> +  /* retab */
> +  return;
> +}
> +
> +/* { dg-final { scan-assembler-times "pacibsp" 2 } } */
> +/* { dg-final { scan-assembler-times "retab" 2 } } */

  reply	other threads:[~2023-09-05 14:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22 10:38 [PATCH 00/11] aarch64 GCS preliminary patches Szabolcs Nagy
2023-08-22 10:38 ` [PATCH 01/11] aarch64: AARCH64_ISA_RCPC was defined twice Szabolcs Nagy
2023-09-05 14:30   ` Richard Sandiford
2023-08-22 10:38 ` [PATCH 02/11] Handle epilogues that contain jumps Szabolcs Nagy
2023-08-22 11:03   ` Richard Biener
2023-10-12  8:14     ` Richard Sandiford
2023-10-17  9:19       ` Richard Biener
2023-10-19 15:16         ` Jeff Law
2023-08-22 10:38 ` [PATCH 03/11] aarch64: Use br instead of ret for eh_return Szabolcs Nagy
2023-08-23  9:28   ` Richard Sandiford
2023-08-24  9:43     ` Richard Sandiford
2023-08-22 10:38 ` [PATCH 04/11] aarch64: Do not force a stack frame for EH returns Szabolcs Nagy
2023-09-05 14:33   ` Richard Sandiford
2023-08-22 10:38 ` [PATCH 05/11] aarch64: Add eh_return compile tests Szabolcs Nagy
2023-09-05 14:43   ` Richard Sandiford
2023-08-22 10:38 ` [PATCH 06/11] aarch64: Fix pac-ret eh_return tests Szabolcs Nagy
2023-09-05 14:56   ` Richard Sandiford [this message]
2023-08-22 10:38 ` [PATCH 07/11] aarch64: Disable branch-protection for pcs tests Szabolcs Nagy
2023-09-05 14:58   ` Richard Sandiford
2023-08-22 10:39 ` [PATCH 08/11] aarch64,arm: Remove accepted_branch_protection_string Szabolcs Nagy
2023-08-22 10:39 ` [PATCH 09/11] aarch64,arm: Fix branch-protection= parsing Szabolcs Nagy
2023-08-22 10:39 ` [PATCH 10/11] aarch64: Fix branch-protection error message tests Szabolcs Nagy
2023-09-05 15:00   ` Richard Sandiford
2023-10-13 10:29     ` Richard Earnshaw (lists)
2023-10-23 12:28       ` Szabolcs Nagy
2023-08-22 10:39 ` [PATCH 11/11] aarch64,arm: Move branch-protection data to targets Szabolcs Nagy

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=mptledksm6z.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=Kyrylo.Tkachov@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.earnshaw@arm.com \
    --cc=szabolcs.nagy@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).