aboutsummaryrefslogtreecommitdiff
path: root/locale/C-translit.h
diff options
context:
space:
mode:
authorAlan Modra <amodra@gmail.com>2013-08-17 18:30:23 +0930
committerAlan Modra <amodra@gmail.com>2013-10-04 10:35:10 +0930
commitda13146da10360436941e843834c90a9aef5fd7a (patch)
treeb31adbca1c370169d672974f30050ef91444017c /locale/C-translit.h
parent603e84104cdc709c8e7dcbac54b9a585bf8dff78 (diff)
downloadglibc-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 'locale/C-translit.h')
0 files changed, 0 insertions, 0 deletions