Noticed while doing bug 576010. Apparently known to Debian. Their bug tracker says it's failed since 4.5.11.
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
