diff options
author | Joseph Myers <joseph@codesourcery.com> | 2021-09-24 17:59:22 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2021-09-24 17:59:22 +0000 |
commit | b26901b26e0b0b61a151ff18e53bee84d977ef7c (patch) | |
tree | 60f3a6d23615df91267889e01a68369588a6773f /libof-iterator.mk | |
parent | 5ad9d62c3b7438c70452d6a9b2c7810f9f28bf32 (diff) | |
download | glibc-b26901b26e0b0b61a151ff18e53bee84d977ef7c.tar.gz glibc-b26901b26e0b0b61a151ff18e53bee84d977ef7c.tar.xz glibc-b26901b26e0b0b61a151ff18e53bee84d977ef7c.zip |
Fix sysdeps/x86/fpu/s_ffma.c for 32-bit FMA processor case
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.
Diffstat (limited to 'libof-iterator.mk')
0 files changed, 0 insertions, 0 deletions