public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64 Date: Wed, 15 Jan 2014 05:26:00 -0000 [thread overview] Message-ID: <bug-59774-4-yDsyzDBUJn@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-59774-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- Very interesting and good sleuthing! The way this is suppose to work: For G formatting, we compute the equivalent F or E formatting, as defined in the standard, and pass this new format to output_float which then uses the regular existing formatting processes to do the work. This line: (on or about line 1105 in write_float.def newf.u.real.d = m == 0.0 ? d - 1 : -(mid - d - 1) ;\ is suppose to compute the new 'd' from mid and the given "d" and pass that into output_float using the newf fnode structure. In the failing case the new 'd' is being set to zero and being passed on. As far as your 'kludge'. I don't think of it that way, but we should see if there is a way to correctly compute the d_o value where you are using it in output_float. There should be a way. Since the standard defines all we do in terms of F and E formatting, I think we are mishandling something there in output_float. You are very close to the solution here. (of course I could be wrong). Someone on the list once said, if it fixes the bug, its probably good enough. The computer has no feelings about "correctness" of approach.
next prev parent reply other threads:[~2014-01-15 5:26 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-01-12 0:56 [Bug libfortran/59774] New: " jvdelisle at gcc dot gnu.org 2014-01-12 1:36 ` [Bug libfortran/59774] " dominiq at lps dot ens.fr 2014-01-12 1:48 ` [Bug libfortran/59774] [Regression] " jvdelisle at gcc dot gnu.org 2014-01-12 2:07 ` jvdelisle at gcc dot gnu.org 2014-01-12 3:59 ` jvdelisle at gcc dot gnu.org 2014-01-12 15:06 ` dominiq at lps dot ens.fr 2014-01-12 15:35 ` dominiq at lps dot ens.fr 2014-01-12 16:15 ` dominiq at lps dot ens.fr 2014-01-12 16:25 ` dominiq at lps dot ens.fr 2014-01-14 22:29 ` dominiq at lps dot ens.fr 2014-01-15 5:26 ` jvdelisle at gcc dot gnu.org [this message] 2014-01-15 22:50 ` dominiq at lps dot ens.fr 2014-01-16 9:31 ` [Bug libfortran/59774] [4.8/4.9 Regression] " dominiq at lps dot ens.fr 2014-01-18 14:36 ` dominiq at lps dot ens.fr 2014-01-19 23:18 ` jvdelisle at gcc dot gnu.org 2014-01-19 23:21 ` jvdelisle at gcc dot gnu.org 2014-01-31 10:49 ` rguenth at gcc dot gnu.org 2014-02-11 9:28 ` [Bug libfortran/59774] [4.8 " dominiq at lps dot ens.fr 2014-02-15 15:49 ` jvdelisle at gcc dot gnu.org 2014-02-15 15:58 ` jvdelisle at gcc dot gnu.org 2014-02-15 16:55 ` jvdelisle at gcc dot gnu.org 2014-02-15 17:27 ` jvdelisle at gcc dot gnu.org
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-59774-4-yDsyzDBUJn@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).