From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24255 invoked by alias); 2 Aug 2004 01:15:22 -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 24247 invoked from network); 2 Aug 2004 01:15:21 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 2 Aug 2004 01:15:21 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 440E447D91; Sun, 1 Aug 2004 18:15:20 -0700 (PDT) Date: Mon, 02 Aug 2004 01:15: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: <20040802011520.GA32638@gnat.com> References: <20040722154456.GG1289@gnat.com> <41058380.6050407@gnu.org> <20040726224546.GB20596@gnat.com> <410676AE.4010001@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410676AE.4010001@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-08/txt/msg00023.txt.bz2 Hello Andrew, On Tue, Jul 27, 2004 at 11:37:18AM -0400, Andrew Cagney wrote: > >>Does long_double's floatformat need to be set? > > > > > >Apparently not. Or I should say that I don't see any evidence that > >it should. > > Check the floating-point tests in structs.exp and call-sc.exp. There's > hopefully also some sort of floating-point.exp test that confirms the > basics. > > Looking at the code, it appears to default to: 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. 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. 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. -- Joel