public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
* [glibc] Fix ffma use of round-to-odd on x86
@ 2021-09-23 21:18 Joseph Myers
  0 siblings, 0 replies; only message in thread
From: Joseph Myers @ 2021-09-23 21:18 UTC (permalink / raw)
  To: glibc-cvs

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=4ed7a383f9a8468194ccaebba3f0fa659003888d

commit 4ed7a383f9a8468194ccaebba3f0fa659003888d
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu Sep 23 21:18:31 2021 +0000

    Fix ffma use of round-to-odd on x86
    
    On 32-bit x86 with -mfpmath=sse, and on x86_64 with
    --disable-multi-arch, the tests of ffma and its aliases (fma narrowing
    from binary64 to binary32) fail.  This is probably the issue reported
    by H.J. in
    <https://sourceware.org/pipermail/libc-alpha/2021-September/131277.html>.
    
    The problem is the use of fenv_private.h macros in the round-to-odd
    implementation.  Those macros are set up to manipulate only one of the
    SSE and 387 floating-point state, whichever is relevant for the type
    indicated by the suffix on the macro name.  But x86 configurations
    sometimes use the ldbl-96 implementation of binary64 fma (that's where
    --disable-multi-arch is relevant for x86_64: it causes the ldbl-96
    implementation to be used, instead of an IFUNC implementation that
    falls back to the dbl-64 version), contrary to the expectations of
    those macros for functions operating on double when __SSE2_MATH__ is
    defined.
    
    This can be addressed by using the default versions of those macros
    (giving x86 its own version of s_ffma.c), as is done for the *f128
    macro variants where it depends on the details of how GCC was
    configured when building libgcc which floating-point state is affected
    by _Float128 arithmetic.  The issue only applies when __SSE2_MATH__ is
    defined, and doesn't apply when __FP_FAST_FMA is defined (because in
    that case, fma will be inlined by the compiler, meaning it's
    definitely an SSE operation; for the same reason, this is not an issue
    for narrowing sqrt, as hardware sqrt is always inlined in that
    implementation for x86), but in other cases it's safest to use the
    default versions of the fenv_private.h macros to ensure things work
    whichever fma implementation is used.
    
    Tested for x86_64 (with and without --disable-multi-arch) and x86
    (with and without -mfpmath=sse).

Diff:
---
 sysdeps/x86/fpu/s_ffma.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/sysdeps/x86/fpu/s_ffma.c b/sysdeps/x86/fpu/s_ffma.c
new file mode 100644
index 0000000000..95c2dcd7b7
--- /dev/null
+++ b/sysdeps/x86/fpu/s_ffma.c
@@ -0,0 +1,46 @@
+/* Fused multiply-add of double value, narrowing the result to float.
+   x86 version.
+   Copyright (C) 2021 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#define f32fmaf64 __hide_f32fmaf64
+#define f32fmaf32x __hide_f32fmaf32x
+#define ffmal __hide_ffmal
+#include <math.h>
+#undef f32fmaf64
+#undef f32fmaf32x
+#undef ffmal
+
+#include <math-narrow.h>
+
+#if defined __SSE2_MATH__ && !defined __FP_FAST_FMA
+/* Depending on the details of the glibc configuration, fma might use
+   either SSE or 387 arithmetic; ensure that both parts of the
+   floating-point state are handled in the round-to-odd code.  */
+# undef libc_feholdexcept_setround
+# define libc_feholdexcept_setround	default_libc_feholdexcept_setround
+# undef libc_feupdateenv_test
+# define libc_feupdateenv_test		default_libc_feupdateenv_test
+#endif
+
+float
+__ffma (double x, double y, double z)
+{
+  NARROW_FMA_ROUND_TO_ODD (x, y, z, float, union ieee754_double, , mantissa1,
+			   false);
+}
+libm_alias_float_double (fma)


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-09-23 21:18 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-23 21:18 [glibc] Fix ffma use of round-to-odd on x86 Joseph Myers

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