http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #7 from kargl at gcc dot gnu.org 2011-03-02 07:13:40 UTC ---
(In reply to comment #6)
> 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 does if one follows IEEE 754. A number with 53-bits
of precision will give at most 17 decimal digits.
> 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.14285571471428284921875000000000
> 0.14285714285714284921269268124888
r8 has 53 bit of precision.
r16 has 113 bits of precision.
r8 has 15 decimal digits. r16 has 35
decimal digits. You're getting well
beyond 15 digits in your r8 output.
> Sometimes it is necessary to specify more decimal digits than necessary in the
> edit descriptor because the magnitude of the result may vary.
Ah no! With IEEE binary64 (ie double precision), you can expect
at most 15 decimal digits. Nothing more and quite often quite
less.
laptop:kargl[203] cat > a.f90
program a
print *, precision(1.d0), digits(1.d0)
end program a
laptop:kargl[204]
laptop:kargl[204] gfc4x -o z a.f90
laptop:kargl[205] ./z
15 53
If you expect more than 15 digits, then I think it may
be profitable to re-read Goldberg's paper.
>
> The Fortran 2008 standard even demands this behaviour (in my interpretation):
>
> ===
> 10.7.2.3.7 I/O rounding mode
gfortran is not a F2008 compiler and it currently does not support
I/O rounding modes. I'll note that your program isn't setting a
rounding mode, so what happens in rounding UP and DOWN is irrelevant.
gfortran by default will use round to nearest.
