| Summary: | sys-libs/glibc's trunc() implementation mishandles large values on alpha (sys-apps/findutils fails its "test-trunc2" test) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matt Turner <mattst88> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alpha |
| Priority: | Normal | Keywords: | UPSTREAM |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.debian.org/599975 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Matt Turner
2016-05-02 04:14:29 UTC
The trunc2 test is actually part of gnulib, which findutils uses. So this isn't a problem with findutils at all.
I think the problem is with glibc's implementation of trunc{,f} on alpha.
Yep:
float.c:
float f = 0x1.0000000000001p+52;
trunc.c:
#include <stdio.h>
#include <math.h>
extern const float f;
int main() {
printf("truncf(%19.17f (%a)) =\n"
" %19.17f (%a)\n",
f, f, truncf(f), truncf(f));
return 0;
}
mattst88@megalith ~ % gcc -g -O2 float.c trunc.c -o trunc -lm
mattst88@megalith ~ % ./trunc
truncf(4503599627370496.00000000000000000 (0x1p+52)) =
4503599358935040.00000000000000000 (0x1.fffffep+51)
I'm working on a fix. Someone else landed a fix for this, and some other fixes in the same area immediately after 2.25 development opened. 062e53c195b4a87754632c7d51254867247698b4^..b74d259fe793499134eb743222cd8dd7c74a31ce Would be nice if they were picked back to our 2.23 and 2.24 ebuilds before we attempt to stabilize them. you need all 4 commits ? cherry picking back to the 2.23/2.24 branches shouldn't be a problem. (In reply to SpanKY from comment #5) > you need all 4 commits ? cherry picking back to the 2.23/2.24 branches > shouldn't be a problem. Yep, might as well, lest we ignore them and they bite us later. (Only the last commit, b74d259fe7 is need to fixe this particular bug) Thanks Mike. i cherry picked those 4 back into the upstream 2.23 & 2.24 branches, then added them to our 2.23 & 2.24 patchsets. i didn't revbump 2.23-r3 or 2.24 since it's just alpha specific, and because 2.24 is still unkeyworded (will do a bump when it moves into ~arch). https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc1e6b9d893813d5c762ffb4d6ae2279b164c779 |