[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #16 from Rick Regan --- I can no longer find any conversions that gcc (I'm using 4.6.3) performs incorrectly, including the examples cited above. It doesn't look like there has been any related code changes in real.c though. Is this an architecture-dependent bug perhaps? When I first tested this three years ago I was on a 32-bit Intel machine; now I'm on a 64-bit machine. Thanks.
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #18 from Rick Regan --- (In reply to Vincent Lefèvre from comment #17) > I confirm that it is an architecture-dependent bug. I can't reproduce any > error with your test program on > http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and- > glibc/ even with old gcc versions, from an x86_64 machine. Thanks for the quick and thorough response! Besides those testcases, I wrote an automated testcase to test gcc conversions; I have not found any incorrect ones. (In a loop, the program generates a random decimal string and puts it in a small C program that it compiles and executes on the fly. The generated C program then checks the result against David Gay's strtod(), the result of which I also coded into the program.) As an aside, I see that you must have an older version of glibc; I have been testing strtod() in glibc 2.18 and I no longer get incorrect conversions. According to this, http://sourceware.org/bugzilla/show_bug.cgi?id=3479, it was fixed in 2.17. (I will be writing this up on my blog soon to reflect the new status of these problems.)
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #19 from Rick Regan --- I've looked into this and found that real.c/real.h use a precision of SIGNIFICAND_BITS, which is dependent on an architecture-dependent value called HOST_BITS_PER_LONG. In addition, SIGNIFICAND_BITS limits the precision to 192 bits on a 64-bit system, and I was able to find an example of an incorrect conversion there: 5.0216813883093451685872615018317116712748411717802652598273e58. (Please see my article http://www.exploringbinary.com/gcc-conversions-are-incorrect-architecture-or-otherwise/ for details.)
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #24 from Rick Regan --- I don't understand -- won't "mpfr_init2 (m, SIGNIFICAND_BITS);" have the same problem? Don't we need to change the computation of SIGNIFICAND_BITS in real.h?
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #28 from Rick Regan --- Yes, that makes sense. I originally (mistakingly) thought that SIGNIFICAND_BITS was the intermediate precision for mpfr_strtofr(), like it was for gcc's original algorithm. Then I talked myself out of the "needs more precision" argument based on my interpretation of your response. So then is the round to zero/stickiness just to avoid double rounding (as opposed to using round to nearest/no stickiness)? BTW, I'm testing out the code. I tried a test I found in float-exact-1.c: it's the literal assigned to the double named d1c. When I run it (on a 64-bit system) with the fix I get 0x0.1p-1022; strtod() (David Gay's and glibc's) gives me 0. Also, before the fix, I get "warning: floating constant truncated to zero" and the conversion is correct; after the fix, no message, and an incorrect conversion.
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #26 from Rick Regan --- So the problem was never lack of precision -- just lack of stickiness. We were seeing higher precision making more conversions work (e.g., more worked with 192 bits than 160), but ultimately, stickiness was required to augment the limited precision. This will fix the architecture-dependent aspect of the bug as well. I suppose you could have fixed the existing algorithm, although admittedly using MPFR is a simple and elegant solution. BTW, why was this fixed now, and not when an MPFR based solution was discussed four/five/six years ago? You certainly could have done it a few weeks ago, before I wrote all those articles :).
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #30 from Rick Regan --- I was running with the unfixed glibc, so that mislead me into thinking that, since it matched David Gay's output, it was right. But the fixed gcc and fixed glibc both get it right (0x0.1p-1022), and David Gay's strtod() gets it wrong (0)! (That's one nasty input -- bit position 1075 is a 1, and the next 1 after that is at bit position 3582.) Thanks for enlightening me. Now it's time to bug Dave Gay...
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #31 from Rick Regan --- Gay's strtod() bug was reported and fixed: http://www.exploringbinary.com/gays-strtod-returns-zero-for-inputs-just-above-2-1075/
[Bug middle-end/21718] real.c rounding not perfect
--- Comment #9 from exploringbinary at gmail dot com 2010-06-04 01:31 --- I discovered two other examples of incorrect rounding in gcc: 1) 0.500166533453693773481063544750213623046875 2) 1.50011102230246251565404236316680908203125 These are both halfway cases. Example 1 has bit 53 equal to 1, so it should round up; gcc rounds down. Example 2 has bit 53 equal to 0, so it should round down; gcc rounds up. I've written an article describing these examples in more detail: http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/ . BTW, why doesn't gcc use David Gay's dtoa.c (http://www.netlib.org/fp/dtoa.c) for correct rounding? -- exploringbinary at gmail dot com changed: What|Removed |Added CC| |exploringbinary at gmail dot | |com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
