From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17826 invoked by alias); 2 Mar 2011 06:45:21 -0000 Received: (qmail 17749 invoked by uid 22791); 2 Mar 2011 06:45:20 -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 06:45:16 +0000 From: "thenlich at users dot sourceforge.net" 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: thenlich at users dot sourceforge.net 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: Severity 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 06:45: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/msg00146.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 Thomas Henlich changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor --- Comment #6 from Thomas Henlich 2011-03-02 06:45:01 UTC --- 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 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.14285714285714284921875000000000 0.14285714285714284921269268124888 Sometimes it is necessary to specify more decimal digits than necessary in the edit descriptor because the magnitude of the result may vary. Now, if the same binary value would always result in the same decimal number, that would make it easier to compare results obtained from the same program, obtained with two different compilers or on different platforms (a method used for program verification). The Fortran 2008 standard even demands this behaviour (in my interpretation): === 10.7.2.3.7 I/O rounding mode 2. In what follows, the term "decimal value" means the exact decimal number as given by the character string, while the term "internal value" means the number actually stored in the processor. For example, in dealing with the decimal constant 0.1, the decimal value is the mathematical quantity 1/10, which has no exact representation in binary form. Formatted output of real data involves conversion from an internal value to a decimal value; formatted input involves conversion from a decimal value to an internal value. 3. When the I/O rounding mode is UP, the value resulting from conversion shall be the smallest representable value that is greater than or equal to the original value. When the I/O rounding mode is DOWN, the value resulting from conversion shall be the largest representable value that is less than or equal to the original value. [etc] === In the example, 0.14285714285714284921269268124888 is the largest representable (with 32 decimal digits) value that is less than the original value (binary 1.001001001001001001001001001001001001001001001001001 * 2^-3 = decimal 0.1428571428571428492126926812488818...). The point is, what the standard demands is the closest approximation that can be represented with the specified output precision. The standard does not state that an implementation may truncate the result after an arbitrary number of decimal digits (even if that number is higher than the possible precision of the internal bit width used).