This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] i386: move ULPs to i686 and regenerate new ones for i586
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Aurelien Jarno <aurelien at aurel32 dot net>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 11 Dec 2015 13:05:21 +0000
- Subject: Re: [PATCH] i386: move ULPs to i686 and regenerate new ones for i586
- Authentication-results: sourceware.org; auth=none
- References: <1449179075-2420-1-git-send-email-aurelien at aurel32 dot net> <alpine dot DEB dot 2 dot 10 dot 1512032223310 dot 1888 at digraph dot polyomino dot org dot uk> <20151204121838 dot GA3000 at aurel32 dot net> <20151211121047 dot GA32440 at aurel32 dot net>
On Fri, 11 Dec 2015, Aurelien Jarno wrote:
> The difference between the two only affects float ULPs for the cos, sin,
> ctan and ctanh functions. The difference can be explained by the fact
> that the SSE2 version of sinf and cosf basically convert the single
> precision input into double precision, do all the computation in double
> precision, and convert back the result to single precision.
>
> I am therefore afraid we won't be able to find a case were the i686 and
> SSE2 versions produce the same error.
In that case maybe we do need a separate file in i686/fpu/multiarch/.
> Interestingly it also seems that the i586 ULPs differ between an AMD and
> Intel CPU for the cacos_downward, cacos_towardzero and cacosh_downward
> double precision functions. Here is one of the failure on an AMD CPU:
>
> Failure: Test: Real part of: cacos_downward (1.0 + 0x1.fp-129 i)
> Result:
> is: 5.33563527698223236644e-20 0x1.f7efbeb8d4f100000000p-65
> should be: 5.33563527698223357014e-20 0x1.f7efbeb8d4f120000000p-65
> difference: 1.20370621524202240815e-35 0x1.00000000000000000000p-116
> ulp : 2.0000
> max.ulp : 1.0000
>
> However the high precision result (at least the one in libm-test.inc) is
> 5.335635276982233498398987585285818977930e-20L. The expected result there
> seems to me rounded upward and not downward, and thus the actual result
> seems to be the correct one. Where am I wrong?
Because MPC is extremely slow for certain cases of complex inverse trig
and hyperbolic functions, those have not moved to using auto-libm-test-in,
and so the results given are rounded to a fixed number of decimal places
and typically are only correct for round-to-nearest (so the computed ulps
errors may be off by 1 in some cases).
I suppose maybe I should arrange for auto-libm-test-out to be split by
function in such a way that outputs for each function are generated
separately; that way, if it takes hours to regenerate
auto-libm-test-out-ca{sin,cos,tan}{,h}, it wouldn't affect normal
regeneration of test results for other functions.
--
Joseph S. Myers
joseph@codesourcery.com