This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
- From: "dominiq at lps dot ens.fr" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 17 Feb 2014 14:44:04 +0000
- Subject: [Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
- Auto-submitted: auto-generated
- References: <bug-60128-4 at http dot gcc dot gnu dot org/bugzilla/>
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.