From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: "Victor L. Do Nascimento" <victor.donascimento@arm.com>,
newlib@sourceware.org
Cc: richard.earnshaw@arm.com
Subject: Re: [PATCH v2] libc: arm: Implement setjmp GCC backwards compatibility.
Date: Fri, 3 Feb 2023 13:07:51 +0000 [thread overview]
Message-ID: <1f8740a9-0014-c473-e3e4-6af842cb18e8@foss.arm.com> (raw)
In-Reply-To: <yw8j8rhfxanl.fsf@arm.com>
On 03/02/2023 11:15, Victor L. Do Nascimento wrote:
> When compiling Newlib for arm targets with GCC 12.1 onward, the
> passing of architecture extension information to the assembler is
> automatic, making the use of .fpu and .arch_extension directives
> in assembly files redundant.
>
> With older versions of GCC, however, these directives must be
> hard-coded into the `arm/setjmp.S' file to allow the assembly of
> instructions concerning the storage and subsequent reloading of the
> floating point registers to/from the jump buffer, respectively.
>
> This patch conditionally adds the `.fpu vfpxd' and `.arch_extension
> mve' directives based on compile-time preprocessor macros concerning
> GCC version and target architectural features, such that both the
> assembly and linking of setjmp.S succeeds for older versions of
> Newlib.
> ---
> newlib/libc/machine/arm/setjmp.S | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/newlib/libc/machine/arm/setjmp.S b/newlib/libc/machine/arm/setjmp.S
> index c615f2428..5401534cd 100644
> --- a/newlib/libc/machine/arm/setjmp.S
> +++ b/newlib/libc/machine/arm/setjmp.S
> @@ -64,6 +64,28 @@
>
> .syntax unified
>
> +/* GCC 12.1 and later will tell the assembler exactly which floating
> + point (or MVE) unit is required and we don't want to override
> + that. Conversely, older versions of the compiler don't pass this
> + information so we need to enable the VFP version that is most
> + appropriate. The choice here should support all suitable VFP
> + versions that the older toolchains can handle. */
> +#if __GNUC__ && __GNUC__ < 12
> +/* Ensure that FPU instructions are correctly compiled and, likewise,
> + the appropriate build attributes are added to the resulting object
> + file. Check whether the MVE extension is present and whether
> + we have support for hardware floating point-operations. VFPxd
> + covers all the cases we need in this file for hardware
> + floating-point and should be compatible with all required FPUs
> + that we need to support. */
> +# if __ARM_FP
> + .fpu vfpxd
> +# endif
> +# if __ARM_FEATURE_MVE
> + .arch_extension mve
> +# endif
> +#endif
> +
> #if __ARM_ARCH_ISA_THUMB == 1 && !__ARM_ARCH_ISA_ARM
> /* ARMv6-M-like has to be implemented in Thumb mode. */
>
Thanks, pushed.
prev parent reply other threads:[~2023-02-03 13:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 11:15 Victor L. Do Nascimento
2023-02-03 13:07 ` Richard Earnshaw [this message]
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=1f8740a9-0014-c473-e3e4-6af842cb18e8@foss.arm.com \
--to=richard.earnshaw@foss.arm.com \
--cc=newlib@sourceware.org \
--cc=richard.earnshaw@arm.com \
--cc=victor.donascimento@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).