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

[Andrew Cagney <cagney@gnu.org>]

>>>> >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?
> 
> 
> Unfortunately, I don't know how to answer that question. I am even
> wondering whether it makes sense or not to ask it. I have searched
> through all the IRIX documents I have here (mostly the N32 ABI handbook,
> as well as the N32/N64 transition guide), and they don't even define
> the format for "long doubles". All they say is that on N32 and N64,
> long double = 128 bits. I am wondering if this aspect is not left
> as a software convention, although that would seem a bit chancy to
> me to rely on a simple software convention for base type
> representations.

Try the compiler to see if it can still generate LE code.  It might give 
a hint.

> Anyway, I don't know :-(.
> 
> 
>>> 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.
> 
> 
> It was a crash. With the change I'm suggesting, we're fixing the crash,
> and also printing/setting the value of long double variables with the
> same precision as doubles (ie we ignore the low half of the long double).

So we need to fix this - no long double shouldn't crash GDB (internal 
error well ok but not crash).  Can you dig up the details?

>>> 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 :-/
> 
> 
> Then let's let the fortran developpers fix it :-).

Or the Ada developers :-)

> I vote for setting the format to ieee-double with a comment.

That would also be wrong.

Closer would be a new 128bit irix floatformat that knew how to unpack 
the first 64-bits.

>>> 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?).
> 
> 
> OK, I will add a blub about this in this PR.
> 
> 
>>> 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.
> 
> 
> I am not sure I agree. I would think that, if the default float format
> is not IEEE, then the debugger will print obviously incorrect values
> most of the time. I think we shouldn't let the IRIX case drive the
> decision, because it is using such a particular format (the feedback
> I've heard about this format is not very positive). What I'm trying
> to say is that, when doing a new port, chances are floats will either
> be IEEE and the default should be fine, or output printed by GDB
> will be obviously wrong because the mantissa size is different, or
> something like that. But I have very little knowledge about floats
> outside of IEEE, so it's not a firm opinion.

To speak from experience, the first users of a new port care little for 
floating point, they are too busy reporting bugs in the backtrace and 
single-step code to care much about anything else.  Only once the 
debugger is thought to be mature do people start to notice that the 
floating-point code has been wrong for years :-(

Here, this never worked.  The only reason we noticed is, I think, 
because tests were added to [indirectly] test it.  When I rewrote 
structs.exp I noticed comments saying don't test long double, it doesn't 
work :-(

Andrew