From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9895 invoked by alias); 5 Feb 2007 16:48:29 -0000 Received: (qmail 9860 invoked by alias); 5 Feb 2007 16:48:13 -0000 Date: Mon, 05 Feb 2007 16:48:00 -0000 Message-ID: <20070205164813.9858.qmail@sourceware.org> From: "joseph at codesourcery dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20061107172025.3479.hack@watson.ibm.com> References: <20061107172025.3479.hack@watson.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/3479] Incorrect rounding in strtod() X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00020.txt.bz2 ------- Additional Comments From joseph at codesourcery dot com 2007-02-05 16:48 ------- Subject: Re: Incorrect rounding in strtod() On Sun, 4 Feb 2007, john at thesalmons dot org wrote: > The attached code checks this condition. It's *much* easier to check > this than to check the more detailed requirement of 7.20.1.3. As a > result, the code doesn't actually prove that glibc is in error. It's > possible that gcc's handling of literal floats is in error. We know GCC's handling of floating-point literals doesn't always get the last bit rounded correctly, but showing this requires specially chosen examples (that I could only find for IEEE quad long double). So the cases here probably don't result from a GCC bug - but it might still be wise to write such tests so that GCC only needs parse a hex float value, so as to disentangle the glibc and GCC issues. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 -- http://sourceware.org/bugzilla/show_bug.cgi?id=3479 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.