This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update x86 ulps for GCC 7 [committed]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 8 Sep 2017 19:58:13 +0000
- Subject: Re: Update x86 ulps for GCC 7 [committed]
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1706232023420.16335@digraph.polyomino.org.uk> <20170624111003.GA284@x4> <alpine.DEB.2.20.1706261039210.21187@digraph.polyomino.org.uk> <20170626110146.GA285@x4>
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