public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/47945] REAL(8) output conversion error on MinGW32 Date: Wed, 02 Mar 2011 07:14:00 -0000 [thread overview] Message-ID: <bug-47945-4-8WW5U9pKZ4@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-47945-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2011-03-02 7:14 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-01 14:00 [Bug libfortran/47945] New: " thenlich at users dot sourceforge.net 2011-03-01 14:01 ` [Bug libfortran/47945] " thenlich at users dot sourceforge.net 2011-03-01 14:02 ` thenlich at users dot sourceforge.net 2011-03-01 14:28 ` schwab@linux-m68k.org 2011-03-01 14:45 ` thenlich at users dot sourceforge.net 2011-03-02 0:22 ` jvdelisle at gcc dot gnu.org 2011-03-02 6:45 ` thenlich at users dot sourceforge.net 2011-03-02 7:14 ` kargl at gcc dot gnu.org [this message] 2011-03-02 7:25 ` burnus at gcc dot gnu.org 2011-03-02 13:49 ` thenlich at users dot sourceforge.net 2011-03-02 16:45 ` burnus at gcc dot gnu.org 2011-03-02 17:04 ` burnus at gcc dot gnu.org 2011-03-02 17:54 ` thenlich at users dot sourceforge.net 2011-03-02 18:02 ` burnus at gcc dot gnu.org 2011-03-02 18:17 ` sgk at troutmask dot apl.washington.edu 2011-03-03 14:04 ` jb at gcc dot gnu.org 2011-03-03 14:58 ` thenlich at users dot sourceforge.net 2011-03-04 6:48 ` thenlich at users dot sourceforge.net 2011-03-04 6:53 ` thenlich at users dot sourceforge.net 2011-03-04 6:54 ` thenlich at users dot sourceforge.net 2011-03-04 6:57 ` thenlich at users dot sourceforge.net
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-47945-4-8WW5U9pKZ4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).