i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs

David Schultz das at FreeBSD.ORG
Sun Feb 13 12:00:56 PST 2005


The following reply was made to PR i386/67469; it has been noted by GNATS.

From: David Schultz <das at FreeBSD.ORG>
To: Bruce Evans <bde at zeta.org.au>
Cc: FreeBSD-gnats-submit at FreeBSD.ORG, freebsd-i386 at FreeBSD.ORG,
	bde at 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.


More information about the freebsd-i386 mailing list