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: Andreas Schwab <schwab at linux-m68k dot org>, <libc-alpha at sourceware dot org>
- Date: Tue, 7 Jan 2014 18:45:16 +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> <87r48lgo4b dot fsf at igel dot home> <Pine dot LNX dot 4 dot 64 dot 1401061535410 dot 20712 at digraph dot polyomino dot org dot uk> <201401071317 dot 38612 dot vapier at gentoo dot org>
On Tue, 7 Jan 2014, Mike Frysinger wrote:
> i've updated the wiki page:
> https://sourceware.org/glibc/wiki/Regeneration
> (go to the bottom to the Math section)
>
> can you guys give it a look to make sure i didn't screw up horribly ?
It's fine as far as it goes, but note also:
* For x86 and x86_64, truncation is only done at the start of each release
freeze, because of the dependence of results on the processor
(transcendental math instructions) and compiler (x86 excess precision).
I suppose the same issue also applies in principle to m68k, but for other
processors truncation is fine at any time (absent compiler / libgcc /
kernel bugs).
* Actually I was thinking of one-digit ulp values [0,10) as being what's
fine, 10-31 as dubious (but that's simply for convenience of grepping for
ulps that are more than one digit, not any sort of policy decision).
* It's a good idea also to watch for ulps for functions that shouldn't
have them (until I automate this bit) - sqrt and fma may be the most
likely to have problems, being the most complicated such functions.
* Rather than leaving the tests to fail it's better to mark them as
expected after filing the bug in Bugzilla, with xfail:<cond> or
xfail-rounding:<cond> or spurious-<whatever>:cond or
missing-<whatever>:cond in auto-libm-test-in, with comments referencing
the bug, and then regenerating auto-libm-test-out. (Marking expected
failures for tests present directly in libm-test.inc is more ad hoc.)
This also applies to failures that don't show up as large ulps but still
cause the test-{float,double,etc} to fail (missing or spurious errno or
exceptions, bad infinity or zero or NaN results, etc.) - file a bug in
Bugzilla then mark as expected to fail. auto-libm-test-in is documented
in the comment at the top of gen-auto-libm-test.c, but the possible need
for recent MPC and MPFR versions to avoid bugs affecting the regeneration
may make this step a bit more complicated.
--
Joseph S. Myers
joseph@codesourcery.com