This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] libm-test.inc: Correctly implement ulp().
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Chris Metcalf <cmetcalf at tilera dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Andreas Jaeger <aj at suse dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 24 May 2013 14:58:59 +0000
- Subject: Re: [PATCH] libm-test.inc: Correctly implement ulp().
- References: <5195593A dot 7090202 at redhat dot com> <51968072 dot 2090606 at suse dot com> <51968291 dot 2010707 at redhat dot com> <519F7BC7 dot 5050107 at tilera dot com>
On Fri, 24 May 2013, Chris Metcalf wrote:
> On 5/17/2013 3:18 PM, Carlos O'Donell wrote:
> > On 05/17/2013 03:09 PM, Andreas Jaeger wrote:
> >> Does this change mean we should regenerate the ULPs for all
> >> architectures from scratch?
> > As part of the final 2.18 release process everyone should be
> > regenerating ulps from scratch.
>
> Are we actually at that stage now? It does seem that Joseph is still
> pouring in his cool code-to-data rework changes for the math tests, and
> presumably it makes sense to hold off regenerating until that's
> complete?
David will say exactly when we're freezing for 2.18 release, at which
point changes requiring ulps updates should no longer be going in and
architecture maintainers can truncate and regenerate their ulps (taking
the usual care about not checking in excessively high ulps, or ulps for
functions such as rint/sqrt/fma/... that shouldn't have any, at least in
the absence of a relevant bug filed in Bugzilla ... note there are such
ulps checked in for fma, fmod, sqrt and cproj at present, but I hope the
latter three will go away on regeneration).
It is of course possible that during the freeze architecture-specific
problems may be fixed to eliminate errors that show up in the regeneration
of ulps.
--
Joseph S. Myers
joseph@codesourcery.com