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/
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 #29 from Joseph S. Myers ---
GCC supports lots of different floating-point formats, not all IEEE, including
variants such as "no subnormals" or "no infinities". Using round to
zero/stickiness allows the existing GCC code that knows ab
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 #27 from Joseph S. Myers ---
No, it was lack of precision. MPFR may need to use many more than
SIGNIFICAND_BITS internally in order to compute a result that is correctly
rounded towards zero to SIGNIFICAND_BITS (plus the ternary value
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 #25 from Joseph S. Myers ---
Rounding to zero and setting a sticky bit based on inexactness works as long as
the internal precision has at least two more bits than the final precision for
which correctly rounded results are required.
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 #23 from Joseph S. Myers ---
*** Bug 55145 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
Joseph S. Myers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #21 from Joseph S. Myers ---
Author: jsm28
Date: Wed Nov 20 14:34:49 2013
New Revision: 205119
URL: http://gcc.gnu.org/viewcvs?rev=205119&root=gcc&view=rev
Log:
PR middle-end/21718
* real.c: Remove comment about decimal string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #20 from Vincent Lefèvre ---
I suppose that for any 54-bit[*] odd integer multiplied by a power of two with
a large exponent (in absolute value), some decimal numbers close to this value
will be affected.
[*] 54-bit for double, 25-bit
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 #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 #17 from Vincent Lefèvre ---
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 v
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 #15 from joseph at codesourcery dot com 2012-11-05 20:49:24 UTC ---
The glibc code is pretty complicated (using glibc's copies of mpn_*
low-level GMP functions for multiple-precision arithmetic) and entangled
with other bits o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #14 from Vincent Lefèvre 2012-11-05
08:12:08 UTC ---
Otherwise, how about taking code from the glibc implementation of
strtof/strtod/strtold? Code in strtod was recently fixed. I don't know about
strtold...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
H.J. Lu changed:
What|Removed |Added
CC||areg.melikadamyan at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #12 from Vincent Lefèvre 2012-11-05
00:16:32 UTC ---
(In reply to comment #11)
> Really I'd consider this just a variant on bug 21718 (real.c rounding not
> perfect). That would ideally be fixed by using MPFR for this in GCC ...
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #11 from H.J. Lu 2012-11-04 23:06:27
UTC ---
From:
http://www.sourceware.org/bugzilla/show_bug.cgi?id=14803#c1
---
Really I'd consider this just a variant on bug 21718 (real.c rounding not
perfect). That would ideally b
--- Comment #10 from joseph at codesourcery dot com 2010-06-05 11:57
---
Subject: Re: real.c rounding not perfect
On Fri, 4 Jun 2010, exploringbinary at gmail dot com wrote:
> BTW, why doesn't gcc use David Gay's dtoa.c (http://www.netlib.org/fp/dtoa.c)
> for correct rounding?
Anyth
--- 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.
--- Comment #8 from joseph at codesourcery dot com 2009-04-20 17:30 ---
Subject: Re: real.c rounding not perfect
On Mon, 20 Apr 2009, ghazi at gcc dot gnu dot org wrote:
> How about chucking real.c and using mpfr_t as the internal representation for
> real numbers inside GCC? I guess
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-04-20 17:01 ---
How about chucking real.c and using mpfr_t as the internal representation for
real numbers inside GCC? I guess we still need something to encode/decode
numbers to the target format, but IMHO we'll keep finding these c
--- Comment #6 from neil at gcc dot gnu dot org 2007-10-18 15:24 ---
(In reply to comment #5)
> I believe more than 160 bits are required to get even single-precision numbers
> right with DECIMAL_DIG digits precision and an exponent. I'm going to try and
> prove this by finding an exam
--- Comment #5 from neil at gcc dot gnu dot org 2007-10-11 03:45 ---
(In reply to comment #1)
> We probably don't even get it right for all cases with DECIMAL_DIG digits for
> all long double formats (required by Annex F).
(In reply to comment #2)
> My reading of F.5#2 is that conversio
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-02-05 19:03 ---
Now we always require MPFR, it should be easy to fix this by using MPFR's
facilities for parsing numbers from strings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-29 20:50 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-23 23:55
---
Here is the example requested on IRC showing that we don't get it right with
DECIMAL_DIG digits and IEEE quad long double. Tested with current mainline on
sparc-sun-solaris2.10 as an example target where long
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-23 14:50
---
We probably don't even get it right for all cases with DECIMAL_DIG digits for
all long double formats (required by Annex F).
--
What|Removed |Added
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
32 matches
Mail list logo
