From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8612 invoked by alias); 3 Aug 2004 13:31:39 -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 8598 invoked from network); 3 Aug 2004 13:31:38 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org with SMTP; 3 Aug 2004 13:31:38 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i73DVbFr012969 for ; Tue, 3 Aug 2004 09:31:37 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i73DVasw012964; Tue, 3 Aug 2004 09:31:37 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Aug 2004 09:31:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16655.37815.285599.668840@gargle.gargle.HOWL> Date: Tue, 03 Aug 2004 13:31:00 -0000 From: Paul Koning To: kettenis@jive.nl Cc: brobecker@gnat.com, cagney@gnu.org, 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> <410EF168.3040304@gnu.org> <20040803043906.GZ32638@gnat.com> <200408030726.i737Q9uw013721@juw15.nfra.nl> X-OriginalArrivalTime: 03 Aug 2004 13:31:36.0786 (UTC) FILETIME=[334E1B20:01C4795E] X-SW-Source: 2004-08/txt/msg00065.txt.bz2 >>>>> "Mark" == Mark Kettenis writes: >> I am ok with documenting this approximation in the GDB manual. >> If whoever wants to fix this later, then fine. But in the >> meantime, I think something is better than nothing. Mark> Folks, Please realize that in practice, printing an Mark> approximation is the best we can do anyway. I'm not sure the present case warrants the effort, but I don't think that's true. You could lift the gcc code in real.c, which has conversions between target format and an oversized internal format. With that you would be able to process 128 bit floats correctly on any host. Then again, I'm not sure why MIPS N32 is defined to have 128 bit floats in the first place. It seems rather silly considering that there isn't any such data type in the machine instruction set. paul