* Update x86 ulps for GCC 7 [committed]
@ 2017-06-23 20:24 Joseph Myers
2017-06-24 11:10 ` Markus Trippelsdorf
0 siblings, 1 reply; 5+ messages in thread
From: Joseph Myers @ 2017-06-23 20:24 UTC (permalink / raw)
To: libc-alpha
Testing with GCC 7 for 32-bit x86 showed some ulps differences,
presumably from variation in when values with excess precision get
spilled to the stack and so lose that precision. This patch updates
the libm-test-ulps files accordingly.
Committed.
2017-06-23 Joseph Myers <joseph@codesourcery.com>
* sysdeps/i386/fpu/libm-test-ulps: Update.
* sysdeps/i386/i686/fpu/multiarch/libm-test-ulps: Likewise.
diff --git a/sysdeps/i386/fpu/libm-test-ulps b/sysdeps/i386/fpu/libm-test-ulps
index 0fc5090..5ab1589 100644
--- a/sysdeps/i386/fpu/libm-test-ulps
+++ b/sysdeps/i386/fpu/libm-test-ulps
@@ -1629,9 +1629,9 @@ ildouble: 1
ldouble: 1
Function: "j0":
-double: 1
+double: 2
float: 1
-idouble: 1
+idouble: 2
ifloat: 1
ildouble: 2
ldouble: 2
@@ -1653,9 +1653,9 @@ ildouble: 5
ldouble: 5
Function: "j0_upward":
-double: 1
+double: 2
float: 3
-idouble: 1
+idouble: 2
ifloat: 3
ildouble: 4
ldouble: 4
@@ -1678,9 +1678,9 @@ ldouble: 4
Function: "j1_towardzero":
double: 2
-float: 1
+float: 2
idouble: 2
-ifloat: 1
+ifloat: 2
ildouble: 4
ldouble: 4
@@ -2129,9 +2129,9 @@ ldouble: 5
Function: "y0_upward":
double: 1
-float: 2
+float: 3
idouble: 1
-ifloat: 2
+ifloat: 3
ildouble: 3
ldouble: 3
diff --git a/sysdeps/i386/i686/fpu/multiarch/libm-test-ulps b/sysdeps/i386/i686/fpu/multiarch/libm-test-ulps
index 04bc23b..611ae2d 100644
--- a/sysdeps/i386/i686/fpu/multiarch/libm-test-ulps
+++ b/sysdeps/i386/i686/fpu/multiarch/libm-test-ulps
@@ -1631,9 +1631,9 @@ ildouble: 1
ldouble: 1
Function: "j0":
-double: 1
+double: 2
float: 1
-idouble: 1
+idouble: 2
ifloat: 1
ildouble: 2
ldouble: 2
@@ -1655,9 +1655,9 @@ ildouble: 5
ldouble: 5
Function: "j0_upward":
-double: 1
+double: 2
float: 3
-idouble: 1
+idouble: 2
ifloat: 3
ildouble: 4
ldouble: 4
@@ -1680,9 +1680,9 @@ ldouble: 4
Function: "j1_towardzero":
double: 2
-float: 1
+float: 2
idouble: 2
-ifloat: 1
+ifloat: 2
ildouble: 4
ldouble: 4
@@ -2115,9 +2115,9 @@ ldouble: 5
Function: "y0_upward":
double: 1
-float: 2
+float: 3
idouble: 1
-ifloat: 2
+ifloat: 3
ildouble: 3
ldouble: 3
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Update x86 ulps for GCC 7 [committed]
2017-06-23 20:24 Update x86 ulps for GCC 7 [committed] Joseph Myers
@ 2017-06-24 11:10 ` Markus Trippelsdorf
2017-06-26 10:44 ` Joseph Myers
0 siblings, 1 reply; 5+ messages in thread
From: Markus Trippelsdorf @ 2017-06-24 11:10 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
On 2017.06.23 at 20:23 +0000, Joseph Myers wrote:
> Testing with GCC 7 for 32-bit x86 showed some ulps differences,
> presumably from variation in when values with excess precision get
> spilled to the stack and so lose that precision. This patch updates
> the libm-test-ulps files accordingly.
For AMD Ryzen x86_64 I need an additional update:
diff --git a/sysdeps/x86_64/fpu/libm-test-ulps b/sysdeps/x86_64/fpu/libm-test-ulps
index 61da961a57..2f74643d34 100644
--- a/sysdeps/x86_64/fpu/libm-test-ulps
+++ b/sysdeps/x86_64/fpu/libm-test-ulps
@@ -1381,9 +1381,9 @@ ldouble: 3
Function: Imaginary part of "ctan_upward":
double: 2
-float: 1
+float: 2
idouble: 2
-ifloat: 1
+ifloat: 2
ildouble: 3
ldouble: 3
--
Markus
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Update x86 ulps for GCC 7 [committed]
2017-06-24 11:10 ` Markus Trippelsdorf
@ 2017-06-26 10:44 ` Joseph Myers
2017-06-26 11:01 ` Markus Trippelsdorf
0 siblings, 1 reply; 5+ messages in thread
From: Joseph Myers @ 2017-06-26 10:44 UTC (permalink / raw)
To: Markus Trippelsdorf; +Cc: libc-alpha
On Sat, 24 Jun 2017, Markus Trippelsdorf wrote:
> On 2017.06.23 at 20:23 +0000, Joseph Myers wrote:
> > Testing with GCC 7 for 32-bit x86 showed some ulps differences,
> > presumably from variation in when values with excess precision get
> > spilled to the stack and so lose that precision. This patch updates
> > the libm-test-ulps files accordingly.
>
> For AMD Ryzen x86_64 I need an additional update:
Such updates should generally just be committed. In this case (x86_64,
not long double) I'm not clear why you'd have ulps variation between
processors, since excess precision is irrelevant on x86_64 and the x87
transcendental instructions would only be used for long double. But it
could be an fma issue, if $CC $CFLAGS defaults to generating fma
instructions, as that can cause ulps variation across architectures.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Update x86 ulps for GCC 7 [committed]
2017-06-26 10:44 ` Joseph Myers
@ 2017-06-26 11:01 ` Markus Trippelsdorf
2017-09-08 19:58 ` Joseph Myers
0 siblings, 1 reply; 5+ messages in thread
From: Markus Trippelsdorf @ 2017-06-26 11:01 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
On 2017.06.26 at 10:43 +0000, Joseph Myers wrote:
> On Sat, 24 Jun 2017, Markus Trippelsdorf wrote:
>
> > On 2017.06.23 at 20:23 +0000, Joseph Myers wrote:
> > > Testing with GCC 7 for 32-bit x86 showed some ulps differences,
> > > presumably from variation in when values with excess precision get
> > > spilled to the stack and so lose that precision. This patch updates
> > > the libm-test-ulps files accordingly.
> >
> > For AMD Ryzen x86_64 I need an additional update:
>
> Such updates should generally just be committed. In this case (x86_64,
> not long double) I'm not clear why you'd have ulps variation between
> processors, since excess precision is irrelevant on x86_64 and the x87
> transcendental instructions would only be used for long double. But it
> could be an fma issue, if $CC $CFLAGS defaults to generating fma
> instructions, as that can cause ulps variation across architectures.
Yes, it should be an fma issue because I used "march=native" (which
turns on -mfma).
I don't have write access, so it would be nice if somebody could commit
the patch for me.
Thanks.
--
Markus
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Update x86 ulps for GCC 7 [committed]
2017-06-26 11:01 ` Markus Trippelsdorf
@ 2017-09-08 19:58 ` Joseph Myers
0 siblings, 0 replies; 5+ messages in thread
From: Joseph Myers @ 2017-09-08 19:58 UTC (permalink / raw)
To: Markus Trippelsdorf; +Cc: libc-alpha
On Mon, 26 Jun 2017, Markus Trippelsdorf wrote:
> On 2017.06.26 at 10:43 +0000, Joseph Myers wrote:
> > On Sat, 24 Jun 2017, Markus Trippelsdorf wrote:
> >
> > > On 2017.06.23 at 20:23 +0000, Joseph Myers wrote:
> > > > Testing with GCC 7 for 32-bit x86 showed some ulps differences,
> > > > presumably from variation in when values with excess precision get
> > > > spilled to the stack and so lose that precision. This patch updates
> > > > the libm-test-ulps files accordingly.
> > >
> > > For AMD Ryzen x86_64 I need an additional update:
> >
> > Such updates should generally just be committed. In this case (x86_64,
> > not long double) I'm not clear why you'd have ulps variation between
> > processors, since excess precision is irrelevant on x86_64 and the x87
> > transcendental instructions would only be used for long double. But it
> > could be an fma issue, if $CC $CFLAGS defaults to generating fma
> > instructions, as that can cause ulps variation across architectures.
>
> Yes, it should be an fma issue because I used "march=native" (which
> turns on -mfma).
> I don't have write access, so it would be nice if somebody could commit
> the patch for me.
Now committed.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-09-08 19:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-23 20:24 Update x86 ulps for GCC 7 [committed] Joseph Myers
2017-06-24 11:10 ` Markus Trippelsdorf
2017-06-26 10:44 ` Joseph Myers
2017-06-26 11:01 ` Markus Trippelsdorf
2017-09-08 19:58 ` 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).