Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@gnat.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/mips] 128-bit long doubles for N32/N64
Date: Mon, 02 Aug 2004 01:15:00 -0000	[thread overview]
Message-ID: <20040802011520.GA32638@gnat.com> (raw)
In-Reply-To: <410676AE.4010001@gnu.org>

Hello Andrew,

On Tue, Jul 27, 2004 at 11:37:18AM -0400, Andrew Cagney wrote:
> >>Does long_double's floatformat need to be set?
> >
> >
> >Apparently not. Or I should say that I don't see any evidence that
> >it should.
> 
> Check the floating-point tests in structs.exp and call-sc.exp.  There's 
> hopefully also some sort of floating-point.exp test that confirms the 
> basics.
> 
> Looking at the code, it appears to default to:

You're right. The floatformat for long double on mips-irix right now
is the default floatformat_ieee_double_big. In pratice, I think this
is not so bad.

A collegue or mine kindly explained to me how the doubles pair work
to implement long doubles on IRIX. Basically, the high double holds
the result of the operation rounded to double, and the low double holds
the difference between the exact result and the rounded result. So
"high" + "low" holds the result with added precision, but "high"
contains the result rounded to double precision.

In terms of how this affects the debugger: GDB currently only uses
the high part of the long double, so it loses a bit of precision when
printing long doubles. I don't think this is a problem at all, since
we "only" print doubles with 17 digits. Similarly, I don't think we
lose much when we ask the debugger to change the value of a long double
variable, since I think a user will seldom provide a float with 50+
digits (If I had to do that, I would use the hex value, and write it
in memory directly).

Can we do better, and have a more accurate float format? It seems
to me that the answer would be: not with the current floatformat
description. Not a big deal, as far as I am concerned.

There is one little sticky point: When calling a procedure with a long
double as a parameter, GDB chokes:

        (gdb) call pd (a)
        That operation is not available on integers of more than 8 bytes.

This is an issue indeed, but I think it can be dealt with separately
of the patch I submitted.

Let me know what you think.

-- 
Joel


  reply	other threads:[~2004-08-02  1:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-22 15:44 Joel Brobecker
2004-07-26 22:19 ` Andrew Cagney
2004-07-26 22:45   ` Joel Brobecker
2004-07-27 15:37     ` Andrew Cagney
2004-08-02  1:15       ` Joel Brobecker [this message]
2004-08-02  1:43         ` Michael Chastain
2004-08-02 18:31         ` Andrew Cagney
2004-08-03  1:13           ` Joel Brobecker
2004-08-03  1:59             ` Andrew Cagney
2004-08-03  4:39               ` Joel Brobecker
2004-08-03  7:27                 ` Mark Kettenis
2004-08-03 13:31                   ` Paul Koning
2004-08-04  4:00                     ` Alexandre Oliva
2004-08-04  7:19                     ` Mark Kettenis
2004-08-03  3:19             ` Michael Chastain

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=20040802011520.GA32638@gnat.com \
    --to=brobecker@gnat.com \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    /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