public inbox for newlib-cvs@sourceware.org help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@sourceware.org> To: newlib-cvs@sourceware.org Subject: [newlib-cygwin] libc: arm: Implement setjmp GCC backwards compatibility. Date: Fri, 3 Feb 2023 13:07:36 +0000 (GMT) [thread overview] Message-ID: <20230203130736.752143858C52@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=c6e601de84ea9f2be2b026c609cc3c1fe82a3103 commit c6e601de84ea9f2be2b026c609cc3c1fe82a3103 Author: Victor L. Do Nascimento <victor.donascimento@arm.com> Date: Fri Feb 3 11:15:26 2023 +0000 libc: arm: Implement setjmp GCC backwards compatibility. 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. Diff: --- 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..5e5952296 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. */
reply other threads:[~2023-02-03 13:07 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20230203130736.752143858C52@sourceware.org \ --to=rearnsha@sourceware.org \ --cc=newlib-cvs@sourceware.org \ /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: linkBe 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).