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

[Andrew Cagney <cagney@gnu.org>]

> 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.

What happens little endian?

> 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.

To back up a little.

Was the problem that GDB was dieing during a testsuite run, or that 
users were complaining "long double" didn't work on IRIX?  I'd suspect 
the former as, as far as I can tell, IRIX's long-double has always been 
broken.

If we do the above (I'm guessing that you're suggesting that long double 
format get explicitly set to ieee-double + a comment), then we get into 
the territory where GDB is lieing to the user - it appears to support 
something but doesn't.  I prefer to see us fix the problems, or at least 
make it clear to the user that the feature isn't supported.  While 
neither you nor I care about the last few bits of 128-bit 
floating-point, I can bet you that are fortran programmers that do :-/

We at least need to update http://sources.redhat/com/gdb/bugs/866
so we've more weight behind the argument that floatformat should be 
replaced (by GCC's code, hmm, does GCC's cross-platform floating-point 
library handle this?).

I also think that the architecture vector should stop supplying a 
default value for unknown float-formats -> here its clearly wrong and 
very hard to detect.

> 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.

thoughts?
Andrew