[Bug fortran/57399] New: errors in formatted print of floating numbers

[Bug fortran/57399] New: errors in formatted print of floating numbers

[custos.mentis at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57399

            Bug ID: 57399
           Summary: errors in formatted print of floating numbers
           Product: gcc
           Version: 4.6.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: custos.mentis at gmail dot com

A simple test of formated print

write(*,"(1e10.2,1x,f8.2,1x,1pe10.2,1x,f8.2)") 100.0, 100.0, 100.0, 100.0

results in wrong output:

0.10E+03   100.00   1.00E+02  1000.00
                              -------

All four numbers should be equal 100.0, but the last one is 10 x larger!

I am using GNU Fortran (Gentoo 4.6.3 p1.13, pie-0.5.2) 4.6.3

[Bug fortran/57399] errors in formatted print of floating numbers

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57399

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |burnus at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Closed as INVALID - if you disagree, reopen with stating a good reason.


The output looks okay to me - and I get the same result with other compilers.

You really shouldn't use the P edit descriptor - it makes everything very
complicated and can lead to surprising results. See Fortran 2008's "10.8.5 P
editing" at http://gcc.gnu.org/wiki/GFortranStandards for the interpretation of
the "P".

"The kP edit descriptor temporarily changes (9.5.2) the scale factor for the
connection to k. The scale factor affects the editing done by the F, E, EN, ES,
D, and G edit descriptors for numeric quantities."


Your format uses:
  1pe10.2

If one applies the following on "100.0" (or "0.10e03"), one obtains "1.00e02":

"On output, with E and D editing, the effect is that the signi\fcand (R414) part
of the quantity to be produced is multiplied by 10k and the exponent is reduced
by k."

For the next item (after the "1pe10.2,1x,") in the same WRITE statement, the
format uses the following edit descriptor:
   f8.2
which is equivalent to
   1pf8.2
as the 1P edit descriptor is still active.

The standard now states the following for the k P F edit descriptor:

"On output, with F output editing, the effect is that the externally
represented number equals the internally represented number multiplied by
10**k; the internal value is converted using the I/O rounding mode and then the
scale factor is applied to the converted decimal value."

Thus, you have "100.0" multiplied by 10**1 = 10, which gives "1000.0". That is
also the result you get.
>From gcc-bugs-return-423066-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 24 14:35:45 2013
Return-Path: <gcc-bugs-return-423066-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26757 invoked by alias); 24 May 2013 14:35:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26701 invoked by uid 48); 24 May 2013 14:35:42 -0000
From: "rakdver at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above
Date: Fri, 24 May 2013 14:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rakdver at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57343-4-yz5kZKVlGb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57343-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57343-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg01739.txt.bz2
Content-length: 1307

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW343

--- Comment #7 from Zdenek Dvorak <rakdver at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> We then fall to
>
>   if (multiple_of_p (TREE_TYPE (c), c, s))
>     {
>       /* If C is an exact multiple of S, then its value will be reached
> before
>          the induction variable overflows (unless the loop is exited in some
>          other way before).  Note that the actual induction variable in the
>          loop (which ranges from base to final instead of from 0 to C) may
>          overflow, in which case BNDS.up will not be giving a correct upper
>          bound on C; thus, BNDS_U_VALID had to be computed in advance.  */
>       no_overflow = true;
>       exit_must_be_taken = true;
>
> which ends up with no_overflow = true and things going downhill from here.

This is the problem -- multiple_of_p claims that (var * 100) is a multiple of
100, which is not the case if the multiplication overflows.  I am not sure
whether this is an expected behavior of multiple_of_p, or whether this could
cause problems in its other uses.

A conservative fix here would be to replace the multiple_of_p test here by some
safer tests -- important special cases are:
1) both c and s are constants and c is a multiple of s
2) s = 1

[Bug fortran/57399] errors in formatted print of floating numbers

[custos.mentis at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57399

--- Comment #2 from Grzegorz Kowal <custos.mentis at gmail dot com> ---
Yes, you are right. Silly me. Thanks for your clear explanation and quick
response!