Summary: | Double overflow/underflow handling broken (after exp()) | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Andres Freund <andres+bugs.kde.org> |
Component: | memcheck | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | andres+bugs.kde.org |
Priority: | NOR | ||
Version: | 3.9.0.SVN | ||
Target Milestone: | --- | ||
Platform: | Debian unstable | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | testcase for broken underflow behaviour |
Description
Andres Freund
2013-10-29 12:21:05 UTC
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. |