diff options
| author | Alan Modra <amodra@gmail.com> | 2013-08-17 18:30:23 +0930 |
|---|---|---|
| committer | Alan Modra <amodra@gmail.com> | 2013-10-04 10:35:10 +0930 |
| commit | da13146da10360436941e843834c90a9aef5fd7a (patch) | |
| tree | b31adbca1c370169d672974f30050ef91444017c /ChangeLog | |
| parent | 603e84104cdc709c8e7dcbac54b9a585bf8dff78 (diff) | |
| download | glibc-da13146da10360436941e843834c90a9aef5fd7a.tar glibc-da13146da10360436941e843834c90a9aef5fd7a.tar.gz glibc-da13146da10360436941e843834c90a9aef5fd7a.tar.bz2 glibc-da13146da10360436941e843834c90a9aef5fd7a.zip | |
PowerPC floating point little-endian [10 of 15]
http://sourceware.org/ml/libc-alpha/2013-07/msg00201.html
These two functions oddly test x+1>0 when a double x is >= 0.0, and
similarly when x is negative. I don't see the point of that since the
test should always be true. I also don't see any need to convert x+1
to integer rather than simply using xr+1. Note that the standard
allows these functions to return any value when the input is outside
the range of long long, but it's not too hard to prevent xr+1
overflowing so that's what I've done.
(With rounding mode FE_UPWARD, x+1 can be a lot more than what you
might naively expect, but perhaps that situation was covered by the
x - xrf < 1.0 test.)
* sysdeps/powerpc/fpu/s_llround.c (__llround): Rewrite.
* sysdeps/powerpc/fpu/s_llroundf.c (__llroundf): Rewrite.
Diffstat (limited to 'ChangeLog')
| -rw-r--r-- | ChangeLog | 5 |
1 files changed, 5 insertions, 0 deletions
@@ -1,5 +1,10 @@ 2013-10-04 Alan Modra <amodra@gmail.com> + * sysdeps/powerpc/fpu/s_llround.c (__llround): Rewrite. + * sysdeps/powerpc/fpu/s_llroundf.c (__llroundf): Rewrite. + +2013-10-04 Alan Modra <amodra@gmail.com> + * sysdeps/powerpc/fpu/s_float_bitwise.h (__float_and_test28): Don't use vector int constants. (__float_and_test24, __float_and8, __float_get_exp): Likewise. |