public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: <libc-alpha@sourceware.org>
Subject: Fix sysdeps/x86/fpu/s_ffma.c for 32-bit FMA processor case [committed]
Date: Fri, 24 Sep 2021 17:59:58 +0000	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2109241759380.4038824@digraph.polyomino.org.uk> (raw)

It turns out the __SSE2_MATH__ conditional in sysdeps/x86/fpu/s_ffma.c
does not cover all cases where the x86 fenv_private.h macros might
manipulate one of the SSE and 387 floating-point state, while the
actual fma implementation uses the other.  Specifically, in the 32-bit
case, with a compiler not defaulting to -mfpmath=sse, but testing on a
processor with hardware FMA support, the multiarch fma function
implementations will end up using SSE, while the fenv_private.h macros
will use the 387 state for double.  Change the conditional to use the
default macros rather than the optimized ones in all cases except when
the compiler inlines an fma instruction (in which case, since all
those instructions are SSE instructions and -mfpmath=sse must be in
effect for them to be inlined, the optimized macros will only use the
SSE state and it's OK for them to only use the SSE state).

Tested for x86_64 and x86.  H.J. reports in
<https://sourceware.org/pipermail/libc-alpha/2021-September/131367.html>
that it fixes the problems he observed.

---

Committed.

diff --git a/sysdeps/x86/fpu/s_ffma.c b/sysdeps/x86/fpu/s_ffma.c
index 95c2dcd7b7..da4bb55f9a 100644
--- a/sysdeps/x86/fpu/s_ffma.c
+++ b/sysdeps/x86/fpu/s_ffma.c
@@ -27,10 +27,14 @@
 
 #include <math-narrow.h>
 
-#if defined __SSE2_MATH__ && !defined __FP_FAST_FMA
+#ifndef __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.  */
+   floating-point state are handled in the round-to-odd code.  If
+   __FP_FAST_FMA is defined, that implies that the compiler is using
+   SSE floating point and that the fma call will be inlined, so the
+   x86 macros will work with only the SSE state and that is
+   sufficient.  */
 # undef libc_feholdexcept_setround
 # define libc_feholdexcept_setround	default_libc_feholdexcept_setround
 # undef libc_feupdateenv_test

-- 
Joseph S. Myers
joseph@codesourcery.com

                 reply	other threads:[~2021-09-24 18:00 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=alpine.DEB.2.22.394.2109241759380.4038824@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=libc-alpha@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).