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.


  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: link
Be 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).