This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA/mips] 128-bit long doubles for N32/N64


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]