From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25079 invoked by alias); 2 Mar 2011 07:14:09 -0000 Received: (qmail 25071 invoked by uid 22791); 2 Mar 2011 07:14:08 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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, 02 Mar 2011 07:14:03 +0000 From: "kargl at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/47945] REAL(8) output conversion error on MinGW32 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: minor X-Bugzilla-Who: kargl at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC 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, 02 Mar 2011 07:14: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-03/txt/msg00147.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 kargl at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org 2011-03-02 07:13:40 UTC --- (In reply to comment #6) > I still think it makes sense to demand that the same binary value always > converts to the same decimal number, regardless of compiler vendor, or > platform. It does if one follows IEEE 754. A number with 53-bits of precision will give at most 17 decimal digits. > It should even be the same for the same internal value, when the variables are > of different real kinds (which now it isn't, on mingw). Consider: > > real(8) :: r8 > real(16) :: r16 > > r8 = .14285714285714286d0 > r16 = r8 > write(*, '(f35.32)') r8 > write(*, '(f35.32)') r16 > end > > output: > 0.14285571471428284921875000000000 > 0.14285714285714284921269268124888 r8 has 53 bit of precision. r16 has 113 bits of precision. r8 has 15 decimal digits. r16 has 35 decimal digits. You're getting well beyond 15 digits in your r8 output. > Sometimes it is necessary to specify more decimal digits than necessary in the > edit descriptor because the magnitude of the result may vary. Ah no! With IEEE binary64 (ie double precision), you can expect at most 15 decimal digits. Nothing more and quite often quite less. laptop:kargl[203] cat > a.f90 program a print *, precision(1.d0), digits(1.d0) end program a laptop:kargl[204] laptop:kargl[204] gfc4x -o z a.f90 laptop:kargl[205] ./z 15 53 If you expect more than 15 digits, then I think it may be profitable to re-read Goldberg's paper. > > The Fortran 2008 standard even demands this behaviour (in my interpretation): > > === > 10.7.2.3.7 I/O rounding mode gfortran is not a F2008 compiler and it currently does not support I/O rounding modes. I'll note that your program isn't setting a rounding mode, so what happens in rounding UP and DOWN is irrelevant. gfortran by default will use round to nearest.