From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22539 invoked by alias); 3 Aug 2004 01:13:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22527 invoked from network); 3 Aug 2004 01:13:39 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 3 Aug 2004 01:13:39 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id BF06D47D91; Mon, 2 Aug 2004 18:13:38 -0700 (PDT) Date: Tue, 03 Aug 2004 01:13:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/mips] 128-bit long doubles for N32/N64 Message-ID: <20040803011338.GY32638@gnat.com> References: <20040722154456.GG1289@gnat.com> <41058380.6050407@gnu.org> <20040726224546.GB20596@gnat.com> <410676AE.4010001@gnu.org> <20040802011520.GA32638@gnat.com> <410E886E.1060702@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410E886E.1060702@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-08/txt/msg00052.txt.bz2 > >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. 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). > 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 :-). I vote for setting the format to ieee-double with a comment. > 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. -- Joel