Date: Wed, 9 Jun 2004 21:24:52 +0000 (UTC) From: David Schultz <das@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/lib/msun/src s_rintf.c Message-ID: <200406092124.i59LOqsL049229@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
das 2004-06-09 21:24:52 UTC
FreeBSD src repository
Modified files:
lib/msun/src s_rintf.c
Log:
Fix a bug where rintf() rounded the wrong way in round-to-nearest mode
on all inputs of the form x.75, where x is an even integer and
log2(x) = 21. A similar problem occurred when rounding upward.
The bug involves the following snippet copied from rint():
i>>=1;
if((i0&i)!=0) i0 = (i0&(~i))|((0x100000)>>j0);
The constant 0x100000 should be 0x200000. Apparently this case was
never tested.
It turns out that the bit manipulation is completely superfluous
anyway, so remove it. (It tries to simulate 90% of the rounding
process that the FPU does anyway.) Also, the special case of +-0 is
handled twice (in different ways), so remove the second instance.
Throw in some related simplifications from bde:
- Work around a bug where gcc fails to clip to float precision by
declaring two float variables as volatile. Previously, we
tricked gcc into generating correct code by declaring some
float constants as doubles.
- Remove additional superfluous bit manipulation.
- Minor reorganization.
- Include <sys/types.h> explicitly.
Note that some of the equivalent lines in rint() also appear to be
unnecessary, but I'll defer to the numerical analysts who wrote it,
since I can't test all 2^64 cases.
Discussed with: bde
Revision Changes Path
1.9 +7 -26 src/lib/msun/src/s_rintf.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406092124.i59LOqsL049229>