Update x86 ulps for GCC 7 [committed]

  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:
  

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.
  

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.
  

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.