Hi, The manpage for exp(3) states: If x is a NaN, a NaN is returned. If x is positive infinity, positive infinity is returned. If x is negative infinity, +0 is returned. If the result underflows, a range error occurs, and zero is returned. If the result overflows, a range error occurs, and the functions return +HUGE_VAL, +HUGE_VALF, or +HUGE_VALL, respectively. So, exp(-large_number) should set errno=ERANGE and return 0. The attached test program does so once for float and once for double and shows that it works that way when executed natively. When executed within valgrind --tool=memcheck inf, errno=ERANGE is returned instead. To me this does *not* look like #197915. Reproducible: Always Steps to Reproduce: 1. gcc -Wall -lm /tmp/valgrind-float.c -o /tmp/valgrind-float 2. /tmp/valgrind-float; 3. valgrind -q /tmp/valgrind-float Actual Results: double orig: -854.000000, result: inf, errno: Numerical result out of range float orig: -200.000000, result: inf, errno: Numerical result out of range Expected Results: double orig: -854.000000, result: 0.000000, errno: Numerical result out of range float orig: -200.000000, result: 0.000000, errno: Numerical result out of range
Created attachment 83200 [details] testcase for broken underflow behaviour
Is this for a 32- or 64-bit process?
Hi, On 2014-05-09 12:16:32 +0000, Julian Seward wrote: > https://bugs.kde.org/show_bug.cgi?id=326821 > > --- Comment #2 from Julian Seward <jseward@acm.org> --- > Is this for a 32- or 64-bit process? It was a 64bit process. But apparently somebody was nice enough to fix it independent of this bug. Because I can't reproduce it anymore in the current debian version 1:3.9.0-5. And it doesn't look like any of debian's patches are responsible. Thanks, Andres
Are you absolutely sure about that? I think it is possible that the problem is still there, but the code generated by no longer uses the problematic instruction(s).
Hi, On 2014-05-12 13:54:34 +0000, Julian Seward wrote: > https://bugs.kde.org/show_bug.cgi?id=326821 > > --- Comment #4 from Julian Seward <jseward@acm.org> --- > Are you absolutely sure about that? I think it is possible > that the problem is still there, but the code generated by > no longer uses the problematic instruction(s). No, I am not absolutely sure of it. The bug was triggered inside exp()/expf() it's glibc (via libm) code. I unfortunately don't know which version of glibc was installed back then. It's quite possible that they changed the implementation in some way leading to less problematic instructions to be used. I've found an old valgrind binary that used to reproduce the problem lying around and it does *not* reproduce the problem anymore against a newly compiled binary. On the other hand, looking at eglibc's source there doesn't seem to have been any recent changes to expf()'s implementation (including __finitef, __expf_finite) and it seems to be primarily written in handrolled asm making compiler changes being relevant less likely. Additionally I can tell you that it used to make postgres' testsuite fail and it doesn't anymore for a while. Greetings, Andres Freund
Well, in the absence of any way to repro this now, I'm going to close this. If you have further information please feel free to reopen it.