Date: Sun, 13 Feb 2005 20:00:55 GMT From: David Schultz <das@FreeBSD.ORG> To: freebsd-i386@FreeBSD.org Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs Message-ID: <200502132000.j1DK0tZY050628@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/67469; it has been noted by GNATS.
From: David Schultz <das@FreeBSD.ORG>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG,
bde@FreeBSD.ORG
Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs
Date: Sun, 13 Feb 2005 14:54:33 -0500
On Mon, Feb 14, 2005, Bruce Evans wrote:
> > sqrt isn't transcendental, so it should be faster and correctly
> > rounded on every hardware platform. I found similar results to
>
> I don't know if we can trust the hardware for that. ISTR checking that
> hardware sqrtf gives the same result as fdlibm for possible values for sqrtf.
> This is of course impossible for double sqrt.
Since IEEE 754 specifies sqrt's behavior, and because ucbtest does
a good job of detecting problems with it, hardware designers are
likely to pay more attention to getting it right. After all, it's
possible to have completely broken transcendentals and still claim
IEEE 754 compliance, but you can't do that if your sqrt is broken.
> I fixed the bug that gave unbelievable cycle counts:
>
> %%%
> --- r.c~ Mon Feb 14 02:19:34 2005
> +++ r.c Mon Feb 14 02:22:21 2005
> @@ -45,4 +47,5 @@
> tmax = 0;
> tmin = INT_MAX;
> + total = 0;
> for (i = 0; i < ITER; i++) {
> if (fabs(avg - t[i]) <= sd * 2) {
> %%%
Yeah, I noticed that bug while using the program to do some
measurements for my research. Sorry I forgot to mention it here.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502132000.j1DK0tZY050628>