This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: automatically updating ulps -- any review needed ?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 6 Jan 2014 14:24:54 +0000
- Subject: Re: automatically updating ulps -- any review needed ?
- Authentication-results: sourceware.org; auth=none
- References: <201401051711 dot 28152 dot vapier at gentoo dot org>
On Sun, 5 Jan 2014, Mike Frysinger wrote:
> the ia64 code hasn't had its ulps file regenerated in a long time. i used the
> helper target for regenerating things, and now i'm looking at the diff. but i
Note that the checked-in file should be truncated before running "make
regen-ulps", so as to remove old ulps for tests for which errors have gone
down or whose names have changed.
> for example, i don't know what to make of things like:
> Function: "yn":
> double: 3
> -float: 2
> +float: 3
> idouble: 3
> -ifloat: 2
> +ifloat: 3
> ildouble: 2
> ldouble: 2
Only the diffs at the end of the file for "Maximal error of functions"
need any review, and all that's relevant there is checking for (a) ulps
for functions that shouldn't have any, such as sqrt or fma, and (b) ulps
that are excessively large. There's no precise definition of excessively
large, but I think anything 32 or more can safely be considered
excessively large and most ulps files don't have any entries that are 10
or more. (I'm minded at some point to make libm-test.inc know what
functions shouldn't have ulps and what ulps are considered excessive, and
avoid adding such ulps in regeneration or respecting them where they are
in existing ulps files.)
In the file you've checked in, the only major problems appear to be for
pow:
Function: "pow":
float: 4194304
ifloat: 4194304
Function: "pow_tonearest":
float: 4194304
ifloat: 4194304
For those, you should (a) file a bug in Bugzilla for the problem,
identifying the specific tests with large errors (showing the expected and
actual results from test-float.out), (b) either fix the bug, or mark the
tests as expected to fail in auto-libm-test-in (xfail:flt-32:ia64, say,
with an associated definition of TEST_COND_ia64 in libm-test.inc) and
regenerate auto-libm-test-out, (c) truncate and regenerate libm-test-ulps.
Although, there are also ulps for ctanh that seem a bit high:
Function: Imaginary part of "ctanh":
ildouble: 24
ldouble: 24
But those look like a test that's since changed its name - so truncating
the file before regenerating should eliminate those.
--
Joseph S. Myers
joseph@codesourcery.com