This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Optimized with SSE2 sinf and cof for x86_32
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Dmitrieva Liubov <liubov dot dmitrieva at gmail dot com>
- Cc: <libc-alpha at sourceware dot org>, Ulrich Drepper <drepper at gmail dot com>
- Date: Fri, 22 Jun 2012 21:00:47 +0000
- Subject: Re: Optimized with SSE2 sinf and cof for x86_32
- References: <CAHjhQ91iSZzUSaDs_MRO3AzzS-KjH7nBp=4ze_NoSTyomsbcHg@mail.gmail.com>
On Fri, 22 Jun 2012, Dmitrieva Liubov wrote:
> Our test system observed more than 1e4 ulp errors for |x|>1e4 for
> current GLIBC. New asm versions, provided here, are maximum 0.500121
> ulp for sinf, 0.500573 ulp for cosf.
Please retry that testing with my patch
<http://sourceware.org/ml/libc-alpha/2012-06/msg00650.html> applied. It
fixes at least two cases of large ulps I extracted from the logs you
provided, but there could be other bugs as well that cause large errors
(anything 10ulp or more should probably be considered large, and certainly
outside the range of "known" problems).
Reports from your test system of large inaccuracy of any libm function
(for any of float, double, long double), in any rounding mode, are very
welcome, but please file new bugs for them (separate bugs for each
function) instead of using existing bugs unless it's clear the new problem
has the same underlying cause and fix as the existing report. Reports of
small errors - functions not correctly rounding - are welcome for those
functions that are fully defined by ISO C and IEEE 754 and should always
be correctly rounding (such as rint, fma, sqrt), but for other functions
we generally know and expect that they are not correctly rounding and
additional bug reports of known cases of functions not being correctly
rounding don't particularly help. In all cases, please make sure that bug
reports identify the affected architecture or architectures; x86 and
x86_64 are very often going to have different issues with libm functions.
--
Joseph S. Myers
joseph@codesourcery.com