This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][AArch64] update libm-test-ulps
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Wed, 8 Apr 2015 16:41:03 +0000
- Subject: Re: [PATCH][AArch64] update libm-test-ulps
- Authentication-results: sourceware.org; auth=none
- References: <5523BAB1 dot 5020700 at arm dot com> <alpine dot DEB dot 2 dot 10 dot 1504071654120 dot 20250 at digraph dot polyomino dot org dot uk> <55254CF4 dot 8060508 at arm dot com> <alpine dot DEB dot 2 dot 10 dot 1504081549350 dot 25740 at digraph dot polyomino dot org dot uk> <552555ED dot 9090305 at arm dot com>
On Wed, 8 Apr 2015, Szabolcs Nagy wrote:
> > libm-test-ulps regeneration is considered obvious. (The libm-test.inc
>
> if i manually have to remove files from the source repository
> then it's not obvious..
obvious = commit without review. Truncating / removing libm-test-ulps
before regeneration is a documented procedure to use at least once per
release cycle.
> > #if TEST_COND_ldbl_128ibm
> > /* The documented accuracy of IBM long double division is 3ulp (see
> > libgcc/config/rs6000/ibm-ldouble-format), so do not require
> > better accuracy for libm functions that are exactly defined for
> > other formats. */
> > max_valid_error = exact ? 3 : 14;
> > #else
> > max_valid_error = exact ? 0 : 9;
>
> is more than 9 ulp error considered a bug?
> (ie. shall i send bug reports about it?)
Yes, such bugs should be reported to Bugzilla, if they don't duplicate
existing bugs (we have existing bug reports for Bessel functions, cpow,
lgamma for negative arguments and atan/atan2 in non-default rounding
modes, for example, and if the essential implementation issue is the same
it's not really useful to have extra bug reports just because there are
multiple implementations with the same bug). Similarly, non-duplicate
bugs about any inaccuracy in functions with fully-determined results are
useful.
I encourage people to look for bugs with mpcheck on non-x86_64
architectures (as far as I know the tests described at
<http://www.loria.fr/~zimmerma/glibc/> are for x86_64 only), though I
don't think results for powerpc would be that useful (because too many
issues would arise with bugs in the underlying libgcc arithmetic for
ldbl-128ibm). Especially, tests for ldbl-128 would be useful, and it's
quite likely there are issues in function implementations for 32-bit x86.
Testing with other tools for libm testing is also useful - mpcheck only
covers a limited subset of libm functions, and even within those it covers
I've found issues it missed such as bug 18196.
--
Joseph S. Myers
joseph@codesourcery.com