[Bug 1000498] Re: fmod() incorrectly returns NaN for (some?) denormalized inputs
Bug Watch Updater
1000498 at bugs.launchpad.net
Thu Aug 9 19:26:52 UTC 2012
Launchpad has imported 13 comments from the remote bug at
http://sourceware.org/bugzilla/show_bug.cgi?id=14048.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2012-05-02T09:09:35+00:00 Jkummerow wrote:
I've come across a case where fmod() does not return the expected result. Reduced repro:
------
#include <math.h>
#include <stdio.h>
#include <iostream>
int main() {
double x = 2.225073858507201e-308;
double y = 5e-324;
double z = fmod(x, y);
// printf("result: %g\n", z); // see [1] below.
std::cout << "result: " << z << std::endl;
return 0;
}
------
Expected result: 0
Actual result: -nan
I can repro the bug on both a Gentoo (gcc-4.5.3, kernel 3.3.4) and an
Ubuntu Precise (gcc-4.6.3, kernel 3.2.5) system, which both have
glibc-2.15, and both are x86_64. It works correctly on Ubuntu Lucid
(glibc-2.11, gcc-4.4.2, kernel 2.6.38.8).
Further, it works correctly when compiling with either of -O1, -O2, -O3.
It also works correctly when removing the "std::cout << ..." and
"#include <iostream>" lines, and using the "printf(..." line (marked
[1]) instead.
I've looked at the generated machine code. In the buggy case, glibc's fmod is called directly:
main():
400744: 55 push rbp
400745: 48 89 e5 mov rbp,rsp
400748: 48 83 ec 20 sub rsp,0x20
40074c: 48 b8 ff ff ff ff ff movabs rax,0xfffffffffffff
400753: ff 0f 00
400756: 48 89 45 f8 mov QWORD PTR [rbp-0x8],rax
40075a: b8 01 00 00 00 mov eax,0x1
40075f: 48 89 45 f0 mov QWORD PTR [rbp-0x10],rax
400763: f2 0f 10 4d f0 movsd xmm1,QWORD PTR [rbp-0x10]
400768: f2 0f 10 45 f8 movsd xmm0,QWORD PTR [rbp-0x8]
40076d: e8 de fe ff ff call 400650 <fmod at plt>
400772: f2 0f 11 45 e8 movsd QWORD PTR [rbp-0x18],xmm0
400777: f2 0f 10 45 e8 movsd xmm0,QWORD PTR [rbp-0x18]
40077c: bf dc 08 40 00 mov edi,0x4008dc
400781: b8 01 00 00 00 mov eax,0x1
400786: e8 75 fe ff ff call 400600 <printf at plt>
40078b: b8 00 00 00 00 mov eax,0x0
400790: c9 leave
400791: c3 ret
When I do any of the changes that make it work (e.g. remove the iostream include), g++ decides to inline an FPU-based implementation of fmod (which seems to work as expected) and only calls out to glibc as a fallback:
main():
400604: 55 push rbp
400605: 48 89 e5 mov rbp,rsp
400608: 48 83 ec 40 sub rsp,0x40
40060c: 48 b8 ff ff ff ff ff movabs rax,0xfffffffffffff
400613: ff 0f 00
400616: 48 89 45 f8 mov QWORD PTR [rbp-0x8],rax
40061a: b8 01 00 00 00 mov eax,0x1
40061f: 48 89 45 f0 mov QWORD PTR [rbp-0x10],rax
400623: dd 45 f8 fld QWORD PTR [rbp-0x8]
400626: dd 45 f0 fld QWORD PTR [rbp-0x10]
400629: d9 c0 fld st(0)
40062b: d9 c2 fld st(2)
40062d: d9 f8 fprem
40062f: df e0 fnstsw ax
400631: f6 c4 04 test ah,0x4
400634: 75 f7 jne 40062d <main+0x29>
400636: dd d9 fstp st(1)
400638: dd 5d d8 fstp QWORD PTR [rbp-0x28]
40063b: f2 0f 10 45 d8 movsd xmm0,QWORD PTR [rbp-0x28]
400640: 66 0f 2e c0 ucomisd xmm0,xmm0
400644: 7a 06 jp 40064c <main+0x48>
400646: 66 0f 2e c0 ucomisd xmm0,xmm0
40064a: 74 17 je 400663 <main+0x5f>
40064c: dd 5d c8 fstp QWORD PTR [rbp-0x38]
40064f: f2 0f 10 4d c8 movsd xmm1,QWORD PTR [rbp-0x38]
400654: dd 5d c8 fstp QWORD PTR [rbp-0x38]
400657: f2 0f 10 45 c8 movsd xmm0,QWORD PTR [rbp-0x38]
40065c: e8 af fe ff ff call 400510 <fmod at plt>
400661: eb 04 jmp 400667 <main+0x63>
400663: dd d8 fstp st(0)
400665: dd d8 fstp st(0)
400667: f2 0f 11 45 e8 movsd QWORD PTR [rbp-0x18],xmm0
40066c: f2 0f 10 45 e8 movsd xmm0,QWORD PTR [rbp-0x18]
400671: bf 7c 07 40 00 mov edi,0x40077c
400676: b8 01 00 00 00 mov eax,0x1
40067b: e8 70 fe ff ff call 4004f0 <printf at plt>
400680: b8 00 00 00 00 mov eax,0x0
400685: c9 leave
400686: c3 ret
So, it looks to me like glibc's fmod() doesn't handle this case (max denormalized double modulo min denormalized double) correctly. Am I barking up the wrong tree?
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/0
------------------------------------------------------------------------
On 2012-05-02T15:31:45+00:00 Bugdal wrote:
Using the -fno-builtin option to gcc should make it easier to
test/reproduce this.
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/1
------------------------------------------------------------------------
On 2012-05-03T20:38:51+00:00 Jkummerow wrote:
Indeed, with -fno-builtin the provided test case fails regardless of
-O{1,2,3}.
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/2
------------------------------------------------------------------------
On 2012-06-01T19:09:50+00:00 Jsm28 wrote:
Fixed for 2.16 by:
commit c5bfe3d5ba29d36563f1e4bd4f8d7336093ee6fc
Author: Joseph Myers <joseph at codesourcery.com>
Date: Fri Jun 1 19:05:46 2012 +0000
Fix fmod for subnormals (bug 14048).
Carlos, I think this should go on 2.15 branch as well.
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/4
------------------------------------------------------------------------
On 2012-06-02T12:56:07+00:00 Jkummerow wrote:
Thanks!
I have recompiled glibc-2.15 on my machine with that patch applied manually and
can confirm that it fixes the issue I was seeing.
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/5
------------------------------------------------------------------------
On 2012-06-08T10:34:58+00:00 Jsm28 wrote:
Carlos, the 2.15 backport should also include
commit 1b671feb6115afbc90a7b37be4929d3e0394f311
Author: Adhemerval Zanella <azanella at linux.vnet.ibm.com>
Date: Tue Jun 5 21:31:24 2012 -0300
Fix for wrong ldbl128-ibm fmodl commit
commit 34ae0b3270c67cae0c54ac98b693fdf7d010a206
Author: Adhemerval Zanella <azanella at linux.vnet.ibm.com>
Date: Tue Jun 5 10:13:41 2012 -0300
Fix ldbl128ibm fmodl for subnormals.
to avoid the new tests failing for powerpc.
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/6
------------------------------------------------------------------------
On 2012-06-25T21:39:19+00:00 Jsm28 wrote:
Created attachment 6481
Backport 1/3
Carlos, please review this series of three backports for 2.15 branch.
Tested x86_64.
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/7
------------------------------------------------------------------------
On 2012-06-25T21:41:03+00:00 Jsm28 wrote:
Created attachment 6482
Backport 2/3
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/8
------------------------------------------------------------------------
On 2012-06-25T21:42:42+00:00 Jsm28 wrote:
Created attachment 6483
Backport 3/3
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/9
------------------------------------------------------------------------
On 2012-06-25T21:52:23+00:00 Carlos-odonell wrote:
(In reply to comment #6)
> Created attachment 6481 [details]
> Backport 1/3
>
> Carlos, please review this series of three backports for 2.15 branch. Tested
> x86_64.
All three backports look good to me for 2.15.
My only worry is that we break the testsuite for yet another target.
Shall we drop the testsuite addition from the backport?
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/10
------------------------------------------------------------------------
On 2012-06-25T22:09:16+00:00 Joseph-codesourcery wrote:
On Mon, 25 Jun 2012, carlos_odonell at mentor dot com wrote:
> Shall we drop the testsuite addition from the backport?
The most conservative backport would be just patch 1/3, without the
testsuite addition - 1/3 is fixing the regression in 2.15 (a regression
introduced by the addition of the wordsize-64 version), the other patches
are fixing a failure that showed up for powerpc with the new testcases but
as far as I know that powerpc failure is not a regression.
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/11
------------------------------------------------------------------------
On 2012-06-25T22:22:18+00:00 Carlos-odonell wrote:
(In reply to comment #10)
> On Mon, 25 Jun 2012, carlos_odonell at mentor dot com wrote:
>
> > Shall we drop the testsuite addition from the backport?
>
> The most conservative backport would be just patch 1/3, without the
> testsuite addition - 1/3 is fixing the regression in 2.15 (a regression
> introduced by the addition of the wordsize-64 version), the other patches
> are fixing a failure that showed up for powerpc with the new testcases but
> as far as I know that powerpc failure is not a regression.
The Power failure is still a failure and should be fixed.
Please checkin all three patches *without* the testsuite addition.
I want to avoid people working with a stable branch having testsuite
failures show up out of thin air because we fixed a bug. That's OK for
trunk, but not OK for a stable branch. The new testsuite failure is
difficult and time-consuming for non-experts to diagnose. We hide this
by fixing the bug, and using the regression test to verify the fix, but
then dropping the testcase from the backport.
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/12
------------------------------------------------------------------------
On 2012-06-25T23:16:00+00:00 Jsm28 wrote:
Fixed 2.15 (without testcase) by:
commit b640404bd8c9a281502ccc87ab2ed640c9b4c085
Author: Adhemerval Zanella <azanella at linux.vnet.ibm.com>
Date: Tue Jun 5 21:31:24 2012 -0300
Fix for wrong ldbl128-ibm fmodl commit
(cherry picked from commit 1b671feb6115afbc90a7b37be4929d3e0394f311)
commit c95a1e5f35fa099eba9b2820b461edaaa7765539
Author: Adhemerval Zanella <azanella at linux.vnet.ibm.com>
Date: Tue Jun 5 10:13:41 2012 -0300
Fix ldbl128ibm fmodl for subnormals.
(cherry picked from commit 34ae0b3270c67cae0c54ac98b693fdf7d010a206)
commit 2676061a91c99fa0b2633ceee881ea5bc31de4c2
Author: Joseph Myers <joseph at codesourcery.com>
Date: Fri Jun 1 19:05:46 2012 +0000
Fix fmod for subnormals (bug 14048).
(cherry picked from commit c5bfe3d5ba29d36563f1e4bd4f8d7336093ee6fc)
Reply at: https://bugs.launchpad.net/eglibc/+bug/1000498/comments/13
** Changed in: eglibc
Status: Unknown => Fix Released
** Changed in: eglibc
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/1000498
Title:
fmod() incorrectly returns NaN for (some?) denormalized inputs
Status in Embedded GLIBC:
Fix Released
Status in “eglibc” package in Ubuntu:
Confirmed
Bug description:
See http://sourceware.org/bugzilla/show_bug.cgi?id=14048.
To manage notifications about this bug go to:
https://bugs.launchpad.net/eglibc/+bug/1000498/+subscriptions
More information about the foundations-bugs
mailing list