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
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-c
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 p
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?
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
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 requ
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
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/
--- 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
