From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-443943-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15127 invoked by alias); 17 Feb 2014 14:44:09 -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
Received: (qmail 14993 invoked by uid 48); 17 Feb 2014 14:44:06 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
Date: Mon, 17 Feb 2014 14:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60128-4-neAuHzShsv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60128-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60128-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: 2014-02/txt/msg01700.txt.bz2

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
While preparing a test case, I have been hit by another snag!-(
With the trunk and 4.8, the following test

write(*,"(en15.2)") 98765.
write(*,"(en15.3)") 9876.5
write(*,"(en15.1)") 987.65
write(*,"(en15.2)") 98.765
write(*,"(en15.3)") 9.8765
write(*,"(en15.1)") .98765
write(*,"(en15.2)") .098765
write(*,"(en15.3)") .0098765
write(*,"(en15.1)") .00098765
write(*,"(en15.2)") .000098765
write(*,"(en15.2)") 98735.
write(*,"(en15.3)") 9873.5
write(*,"(en15.1)") 987.35
write(*,"(en15.2)") 98.735
write(*,"(en15.3)") 9.8735
write(*,"(en15.1)") .98735
write(*,"(en15.2)") .098735
write(*,"(en15.3)") .0098735
write(*,"(en15.1)") .00098735
write(*,"(en15.2)") .000098735
end

gives the following output at run time

      98.76E+03
      9.876E+03
      990.0E+00    <- wrong
      98.76E+00
      9.876E+00
      990.0E-03    <- wrong
      98.77E-03
      9.876E-03
      990.0E-06    <- wrong
      98.76E-06
      98.73E+03
      9.873E+03
      990.0E+00    <- wrong
      98.73E+00
      9.873E+00
      990.0E-03    <- wrong
      98.73E-03
      9.873E-03
      990.0E-06    <- wrong
      98.73E-06

while 4.7 gives

      98.77E+03
      9.877E+03
      987.7E+00
      98.76E+00
      9.877E+00
      987.6E-03
      98.77E-03
      9.876E-03
      987.7E-06
      98.76E-06
      98.74E+03
      9.874E+03
      987.3E+00
      98.74E+00
      9.873E+00
      987.3E-03
      98.73E-03
      9.874E-03
      987.4E-06
      98.73E-06

The reason of these wrong code is due to the rounding of x between 0.95*10**d
and 1.0*10**d to 1.*10**d. it follows that the exponent returned by 'nprinted =
DTOA(y,0,tmp);' in '#define EN_PREC(x,y)' is the actual exponent 'e' plus one.
I don't understand why this affects only the cases 'e%3==0' and I have no idea
how this can be fixed -> any help welcomed!.

Note that for the "working" cases I am not fully happy with the rounding: at
least for 98765., 9876.5, 98735., and 9873.5 which have no rounding errors, I
am expecting with round to even on tie: 98.76E+03, 98.76E+03, 98.74E+03, and
98.74E+03.