From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10876 invoked by alias); 11 Jun 2011 06:28:40 -0000 Received: (qmail 10861 invoked by uid 22791); 11 Jun 2011 06:28:39 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-px0-f176.google.com (HELO mail-px0-f176.google.com) (209.85.212.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 11 Jun 2011 06:28:22 +0000 Received: by pxi11 with SMTP id 11so1751935pxi.21 for ; Fri, 10 Jun 2011 23:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.226 with SMTP id s2mr1283799pbc.252.1307773701968; Fri, 10 Jun 2011 23:28:21 -0700 (PDT) Received: by 10.68.58.225 with HTTP; Fri, 10 Jun 2011 23:28:21 -0700 (PDT) In-Reply-To: <4DF25409.1080509@charter.net> References: <4DE8D8D6.5030506@charter.net> <4DF25409.1080509@charter.net> Date: Sat, 11 Jun 2011 08:24:00 -0000 Message-ID: Subject: Re: [patch, libgfortran] PR48906 Wrong rounding results with -m32 From: Janne Blomqvist To: jerry DeLisle Cc: gfortran , gcc patches , Thomas Henlich Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg00894.txt.bz2 On Fri, Jun 10, 2011 at 20:27, jerry DeLisle wrote: > On 06/03/2011 05:51 AM, jerry DeLisle wrote: >> >> Hi, >> >> The attached patch, which includes test cases, fixes this bug by >> eliminating the >> code which used floating point instructions to determine the 'r' value as >> outlined in the Fortran standard under G formatting. >> >> Essentially, the code now examines the d and e values to determine the >> number of >> digits before and after the decimal point and whether or not to display >> the 'E' >> exponent symbol. Adjustments are made for various corner cases, including >> when >> rounding has resulted in a carry. (see PR for details of the trials) >> >> This patch is intrusive. It results in a minor performance improvement. = It >> eliminates a bit of code. >> >> Regression tested on x86-64. >> >> OK for trunk? then later back port to 4.6 after some proving time? > > Attached is updated patch based on comments from Thomas Henlich. =C2=A0Se= e my > comment #33 and subsequent comments in the PR48906 explaining the issue w= ith > test case fmt_g0_6.f08 which is revised by the updated patch. > > Regression tested on X86-64. > > OK for trunk. (please ;) ) Index: gcc/testsuite/gfortran.dg/char4_iunit_1.f03 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- gcc/testsuite/gfortran.dg/char4_iunit_1.f03 (revision 174673) +++ gcc/testsuite/gfortran.dg/char4_iunit_1.f03 (working copy) @@ -24,7 +24,7 @@ program char4_iunit_1 write(string, *) .true., .false. , .true. if (string .ne. 4_" T F T ") call abo= rt write(string, *) 1.2345e-06, 4.2846e+10_8 - if (string .ne. 4_" 1.23450002E-06 42846000000.000000 ") call a= bort + if (string .ne. 4_" 1.234500019E-06 42846000000.000000 ") call a= bort write(string, *) nan, inf I don't agree with this; with the patch we now output 10 significant digits, whereas 9 is sufficient for a binary->ascii->binary roundtrip. So please retain the "reduce d by one when E editing is used" thing for list format and G0. This is just a side effect of using 1PGw.d format for list format and G0 in order to avoid duplicating code, but we don't need to follow this particular craziness that is due to how the scale factor is specified in the standard. Otherwise it looks nice. Good job! FWIW, as this is quite tricky code and not a regression, IMHO we should not backport it. --=20 Janne Blomqvist