From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27736 invoked by alias); 27 Apr 2011 18:37:44 -0000 Received: (qmail 27677 invoked by uid 22791); 27 Apr 2011 18:37:43 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_IB X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Apr 2011 18:37:30 +0000 From: "jb at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/48511] Implement Steele-White algorithm for numeric output X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jb at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 27 Apr 2011 18:37:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg02800.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511 --- Comment #9 from Janne Blomqvist 2011-04-27 18:36:12 UTC --- I've been thinking about this issue now and then over the past few weeks, and funnily enough, while I initially thought this would be a nice improvement, I've subsequently come to the opposite conclusion, namely that this shouldn't be done: - The use case is limited to making G0, and potentially list formatted, output more compact in some cases. So the benefit isn't that big, IMHO. - Even if we can start off with David Gay's code instead of reimplementing from scratch, it means importing and maintaining potentially several thousand lines of very tricky code. - Getting something wrong may not only mean that we get some conversion wrong in the last bit, but as can be seen in the recent issues with PHP and Java, careless usage of Gay's code might lead to an infinite loop. - As Tobias mentioned, there was enough issues with adapting Gay's code for libquadmath that it was replaced with code from glibc. - OTOH, currently we make use of {quadmath_}snprintf and strto{f,,ld,flt128}, which seem to be competently implemented at least on the widely used targets (that is, they provide correctly rounded behavior), and are widely used also outside of gfortran. This should definitely not be underestimated.