From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28423 invoked by alias); 2 Aug 2004 18:31:13 -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 28415 invoked from network); 2 Aug 2004 18:31:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 2 Aug 2004 18:31: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 i72IVCe3005014 for ; Mon, 2 Aug 2004 14:31:12 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i72IVCa25425; Mon, 2 Aug 2004 14:31:12 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B7CC12B9D; Mon, 2 Aug 2004 14:31:10 -0400 (EDT) Message-ID: <410E886E.1060702@gnu.org> Date: Mon, 02 Aug 2004 18:31: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> In-Reply-To: <20040802011520.GA32638@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00038.txt.bz2 > 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