On Fri, 4 Apr 2025, Jacek Caban wrote:
On 4.04.2025 13:42, Martin Storsjö wrote:
On Thu, 3 Apr 2025, Jacek Caban wrote:
From: Billy Laws <blaw...@gmail.com>
---
mingw-w64-crt/math/fma.c | 2 +-
mingw-w64-crt/math/fmaf.c | 2 +-
mingw-w64-crt/math/llrint.c | 2 +-
mingw-w64-crt/math/llrintf.c | 2 +-
mingw-w64-crt/math/llrintl.c | 3 ++-
mingw-w64-crt/math/lrint.c | 14 +++++++-------
mingw-w64-crt/math/lrintf.c | 14 +++++++-------
mingw-w64-crt/math/modf.c | 2 +-
mingw-w64-crt/math/modff.c | 2 +-
mingw-w64-crt/math/modfl.c | 2 +-
mingw-w64-crt/math/signbitl.c | 4 ++--
mingw-w64-crt/math/sqrt.def.h | 2 +-
12 files changed, 26 insertions(+), 25 deletions(-)
This LGTM. It's not all very pretty, but I guess this is how it has to
be... The patch does things in two kinda different ways, either adding an
extra !defined(__arm64ec__) to existing x86_64 ifdefs, or moving the
aarch64 case with an added "|| defined(__arm64ec__)" to the top. It feels a
little inconsistent, but it's probably decided based on what feels best for
each case?
Yes, whenever the code is ARM-specific, I reordered the implementation to
check for __arm64ec__ in addition to __aarch64__. But in cases where there's
a 'generic' fallback in pure C after x86-specific #ifdefs, reordering would
require adding checks for other ARM targets as well, which didn’t seem like
an improvement.
Thanks, that sounds like a reasonable rationale!
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
