On Tue, 1 Apr 2025, Jacek Caban wrote:

In preparation for using naked functions.
---

For the commit message subject, perhaps you could squeeze in an "arm64" there too, as this only covers that function? That goes for all of these patches.

mingw-w64-crt/Makefile.am                     |  4 ++--
mingw-w64-crt/include/internal.h              |  8 ++++++++
mingw-w64-crt/math/arm64/{trunc.S => trunc.c} | 14 +++++---------
mingw-w64-crt/math/arm64/truncf.S             | 16 ----------------
mingw-w64-crt/math/arm64/truncf.c             | 12 ++++++++++++
5 files changed, 27 insertions(+), 27 deletions(-)
rename mingw-w64-crt/math/arm64/{trunc.S => trunc.c} (50%)
delete mode 100644 mingw-w64-crt/math/arm64/truncf.S
create mode 100644 mingw-w64-crt/math/arm64/truncf.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index ba6c6b7d5..745016079 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -705,8 +705,8 @@ src_msvcrtarm64=\
  math/arm64/nearbyint.S \
  math/arm64/nearbyintf.S \
  math/arm64/nearbyintl.S \
-  math/arm64/trunc.S \
-  math/arm64/truncf.S \
+  math/arm64/trunc.c \
+  math/arm64/truncf.c \
  misc/__p___argc.c \
  misc/__p___argv.c \
  misc/__p___wargv.c \
diff --git a/mingw-w64-crt/include/internal.h b/mingw-w64-crt/include/internal.h
index 84d52c991..b30ae0e5f 100644
--- a/mingw-w64-crt/include/internal.h
+++ b/mingw-w64-crt/include/internal.h
@@ -287,6 +287,14 @@ static inline unsigned int __mingw_statusfp(void)
    return flags;
}

+#define __ASM_FUNC_CODE(name,code)  \
+    asm(".text\n\t" \
+        ".p2align 2\n\t" \
+        ".globl " __MINGW64_STRINGIFY(__MINGW_USYMBOL(trunc)) "\n\t"    \
+        ".def " __MINGW64_STRINGIFY(__MINGW_USYMBOL(trunc)) "; .scl 2; .type 32; 
.endef\n\t" \
+        __MINGW64_STRINGIFY(__MINGW_USYMBOL(trunc)) ":\n\t"             \
+        code "\n\t");

Just for the record; I'm not generally a fan of this kind of function (global-scope "inline" asm); IMO it is messy and tricky for the compiler (e.g. wrt LTO).

That said, I'm aware that Wine does use this construct quite a bit, and it does work there, so practically it's probably fine.

(Although I'm not sure how much LTO is tested there. Building mingw-w64-crt with LTO is probably not a recommended setup anyway, but it should mostly work these days. At https://github.com/mstorsjo/llvm-mingw/commits/lto-toolchain I've got a few unmerged things for making use of it.)

Anyway, not an objection to the approach, I know there are good reasons for it - I just wanted to state publicly that I generally don't favour the approach, but see the reasons for it here.

// Martin



_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to