Fix x86_64 -mfpmath=387 float_t, double_t (bug 20787) [committed]

Fix x86_64 -mfpmath=387 float_t, double_t (bug 20787) [committed]

[Joseph Myers]

Bug 20787 reports that, while float_t and double_t for 32-bit x86
properly respect -mfpmath=sse, for x86_64 they fail to reflect
-mfpmath=387, which is valid if unusual and results in FLT_EVAL_METHOD
being 2.  This patch fixes the definitions to respect
__FLT_EVAL_METHOD__ in that case, arranging for the test that the
types correspond with FLT_EVAL_METHOD to be run with both -mfpmath=387
and -mfpmath=sse.

Note: this patch will also have the effect of making float_t and
double_t be long double for x86_64 with -mfpmath=sse+387, when
FLT_EVAL_METHOD is -1.  It seems reasonable for x86_64 to be
consistent with 32-bit x86 in this case (and that definition is
conservatively safe, in that it makes the types correspond to the
widest evaluation format that might be used).

Tested for x86-64 and x86.  Committed.

2016-11-23  Joseph Myers  <joseph@codesourcery.com>

	[BZ #20787]
	* sysdeps/x86/bits/mathdef.h (float_t): Do not define to float if
	[__x86_64__] when __FLT_EVAL_METHOD__ is nonzero.
	(double_t): Do not define to double if [__x86_64__] when
	__FLT_EVAL_METHOD__ is nonzero.
	* sysdeps/x86/fpu/test-flt-eval-method-387.c: New file.
	* sysdeps/x86/fpu/test-flt-eval-method-sse.c: Likewise.
	* sysdeps/x86/fpu/Makefile [$(subdir) = math] (tests): Add
	test-flt-eval-method-387 and test-flt-eval-method-sse.
	[$(subdir) = math] (CFLAGS-test-flt-eval-method-387.c): New
	variable.
	[$(subdir) = math] (CFLAGS-test-flt-eval-method-sse.c): Likewise.

diff --git a/sysdeps/x86/bits/mathdef.h b/sysdeps/x86/bits/mathdef.h
index e61c28a..9423a7f 100644
--- a/sysdeps/x86/bits/mathdef.h
+++ b/sysdeps/x86/bits/mathdef.h
@@ -22,7 +22,8 @@
 #if defined __USE_ISOC99 && defined _MATH_H && !defined _MATH_H_MATHDEF
 # define _MATH_H_MATHDEF	1
 
-# if defined __x86_64__ || (defined __FLT_EVAL_METHOD__ && __FLT_EVAL_METHOD__ == 0)
+# if ((defined __x86_64__ && !defined __FLT_EVAL_METHOD__)		\
+      || (defined __FLT_EVAL_METHOD__ && __FLT_EVAL_METHOD__ == 0))
 /* The x86-64 architecture computes values with the precission of the
    used type.  Similarly for -m32 -mfpmath=sse.  */
 typedef float float_t;		/* `float' expressions are evaluated as `float'.  */
diff --git a/sysdeps/x86/fpu/Makefile b/sysdeps/x86/fpu/Makefile
index b561995..a8047a4 100644
--- a/sysdeps/x86/fpu/Makefile
+++ b/sysdeps/x86/fpu/Makefile
@@ -1,7 +1,11 @@
 ifeq ($(subdir),math)
 libm-support += powl_helper
-tests += test-fenv-sse test-fenv-clear-sse test-fenv-x87 test-fenv-sse-2
+tests += test-fenv-sse test-fenv-clear-sse test-fenv-x87 test-fenv-sse-2 \
+	 test-flt-eval-method-387 test-flt-eval-method-sse
 CFLAGS-test-fenv-sse.c += -msse2 -mfpmath=sse
 CFLAGS-test-fenv-clear-sse.c += -msse2 -mfpmath=sse
 CFLAGS-test-fenv-sse-2.c += -msse2 -mfpmath=sse
+CFLAGS-test-flt-eval-method-387.c += -fexcess-precision=standard -mfpmath=387
+CFLAGS-test-flt-eval-method-sse.c += -fexcess-precision=standard -msse2 \
+				     -mfpmath=sse
 endif
diff --git a/sysdeps/x86/fpu/test-flt-eval-method-387.c b/sysdeps/x86/fpu/test-flt-eval-method-387.c
new file mode 100644
index 0000000..2fb7acf
--- /dev/null
+++ b/sysdeps/x86/fpu/test-flt-eval-method-387.c
@@ -0,0 +1 @@
+#include <test-flt-eval-method.c>
diff --git a/sysdeps/x86/fpu/test-flt-eval-method-sse.c b/sysdeps/x86/fpu/test-flt-eval-method-sse.c
new file mode 100644
index 0000000..2fb7acf
--- /dev/null
+++ b/sysdeps/x86/fpu/test-flt-eval-method-sse.c
@@ -0,0 +1 @@
+#include <test-flt-eval-method.c>

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Fix x86_64 -mfpmath=387 float_t, double_t (bug 20787) [committed]

[Florian Weimer]

On 11/23/2016 06:57 PM, Joseph Myers wrote:
> Bug 20787 reports that, while float_t and double_t for 32-bit x86
> properly respect -mfpmath=sse, for x86_64 they fail to reflect
> -mfpmath=387, which is valid if unusual and results in FLT_EVAL_METHOD
> being 2.  This patch fixes the definitions to respect
> __FLT_EVAL_METHOD__ in that case, arranging for the test that the
> types correspond with FLT_EVAL_METHOD to be run with both -mfpmath=387
> and -mfpmath=sse.

If I read the patch correctly, this changes the float_t type for those 
(obscure) configurations.  Doesn't this warrant a NEWS entry?

Thanks,
Florian

Re: Fix x86_64 -mfpmath=387 float_t, double_t (bug 20787) [committed]

[Joseph Myers]

On Wed, 23 Nov 2016, Florian Weimer wrote:

> On 11/23/2016 06:57 PM, Joseph Myers wrote:
> > Bug 20787 reports that, while float_t and double_t for 32-bit x86
> > properly respect -mfpmath=sse, for x86_64 they fail to reflect
> > -mfpmath=387, which is valid if unusual and results in FLT_EVAL_METHOD
> > being 2.  This patch fixes the definitions to respect
> > __FLT_EVAL_METHOD__ in that case, arranging for the test that the
> > types correspond with FLT_EVAL_METHOD to be run with both -mfpmath=387
> > and -mfpmath=sse.
> 
> If I read the patch correctly, this changes the float_t type for those
> (obscure) configurations.  Doesn't this warrant a NEWS entry?

I've applied this NEWS patch.

diff --git a/NEWS b/NEWS
index 6e256ae..f0e8a1c 100644
--- a/NEWS
+++ b/NEWS
@@ -65,13 +65,20 @@ Version 2.25
   - NaN functions: getpayload, getpayloadf, getpayloadl, setpayload,
     setpayloadf, setpayloadl.
 
+* The functions strfromd, strfromf, and strfroml, from ISO/IEC TS 18661-1:2014,
+  are added to libc.  They convert a floating-point number into string.
+
 * On ColdFire, MicroBlaze, Nios II and SH3, the float_t type is now defined
   to float instead of double.  This does not affect the ABI of any libraries
   that are part of the GNU C Library, but may affect the ABI of other
   libraries that use this type in their interfaces.
 
-* The functions strfromd, strfromf, and strfroml, from ISO/IEC TS 18661-1:2014,
-  are added to libc.  They convert a floating-point number into string.
+* On x86_64, when compiling with -mfpmath=387 or -mfpmath=sse+387, the
+  float_t and double_t types are now defined to long double instead of float
+  and double.  These options are not the default, and this does not affect
+  the ABI of any libraries that are part of the GNU C Library, but it may
+  affect the ABI of other libraries that use this type in their interfaces,
+  if they are compiled or used with those options.
 
 * The <sys/quota.h> header now includes the <linux/quota.h> header.  Support
   for the Linux quota interface which predates kernel version 2.4.22 has

-- 
Joseph S. Myers
joseph@codesourcery.com