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@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@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@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@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 <jos...@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 <azane...@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 <azane...@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 <azane...@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 <azane...@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 <jos...@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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1000498 Title: fmod() incorrectly returns NaN for (some?) denormalized inputs To manage notifications about this bug go to: https://bugs.launchpad.net/eglibc/+bug/1000498/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
