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: 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).