From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6670 invoked by alias); 3 Aug 2004 01:59:15 -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 6655 invoked from network); 3 Aug 2004 01:59:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 3 Aug 2004 01:59:12 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i731xCe3007538 for ; Mon, 2 Aug 2004 21:59:12 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i731xBa19731; Mon, 2 Aug 2004 21:59:11 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 064722B9D; Mon, 2 Aug 2004 21:59:05 -0400 (EDT) Message-ID: <410EF168.3040304@gnu.org> Date: Tue, 03 Aug 2004 01:59:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/mips] 128-bit long doubles for N32/N64 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> <20040803011338.GY32638@gnat.com> In-Reply-To: <20040803011338.GY32638@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00054.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. 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