On 04/25/2011 07:36 AM, Janne Blomqvist wrote:
On Mon, Apr 25, 2011 at 14:44, Jerry DeLisle<jvdeli...@frontier.com> wrote:
On 04/25/2011 03:48 AM, Janne Blomqvist wrote:
Now, for one of the testcase changes:
--- gcc/testsuite/gfortran.dg/char4_iunit_1.f03 (revision 172909)
+++ gcc/testsuite/gfortran.dg/char4_iunit_1.f03 (working copy)
@@ -24,11 +24,11 @@ program char4_iunit_1
write(string, *) .true., .false. , .true.
if (string .ne. 4_" T F T ") call
abort
write(string, *) 1.2345e-06, 4.2846e+10_8
- if (string .ne. 4_" 1.23450002E-06 42846000000.000000 ") call
abort
+ if (string .ne. 4_" 1.234500019E-06 42846000000.000000 ") call
abort
This looks wrong. For correctly rounded REAL(4) output, we need 9
significant digits, but here we print 10.
Well, I bumped it up for defaults based on pr48488 comment #2 shown below.
Yes, that comment in the PR is correct; to guarantee that a
binary->ascii->binary roundtrip preserves the original binary value
(with the default "round to nearest, break on even" rounding mode),
one must output at least {9, 17, 21, 36} significant digits for real
kinds 4, 8, 10, and 16, respectively (yes, I double-checked IEEE
754-2008 that this is indeed correct).
Since for the G edit descriptor d is equivalent to the number of
significant digits, AFAICS the write.c patch below is correct and the
bug must be elsewhere, no?
No.
Look at this example:
program t4
implicit none
character(len=44) :: string
write(*,*) 1.2345e-06, 4.2846e+10_8
write(*,'(1x,1pG16.9e2,1x,1pG25.17e3)') 1.2345e-06, 4.2846e+10_8
write(*,'(1x,1pG15.8e2,1x,1pG25.17e3)') 1.2345e-06, 4.2846e+10_8
end program t4
This gives with the patch:
1.234500019E-06 42846000000.000000
1.234500019E-06 42846000000.000000
1.23450002E-06 42846000000.000000
And without the patch:
1.23450002E-06 42846000000.000000
1.234500019E-06 42846000000.000000
1.23450002E-06 42846000000.000000
d is the number of digits after the decimal point, not the number of significant
digits.
For comaprison, ifort gives:
1.2345000E-06 42846000000.0000
1.234500019E-06 42846000000.000000
1.23450002E-06 42846000000.000000
Ifort chooses to use d=7 for list directed.
With that being said, I do think there is possibly a different bug not related
to the above that I am working on isolating it. Stay tuned.
Jerry
