From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2456 invoked by alias); 3 Mar 2009 05:17:02 -0000 Received: (qmail 2446 invoked by uid 22791); 3 Mar 2009 05:17:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Mar 2009 05:16:55 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0F8BA2BAB56; Tue, 3 Mar 2009 00:16:56 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AgKd23RGG9Jj; Tue, 3 Mar 2009 00:16:55 -0500 (EST) Received: from sdsl-216-220-103-156.dsl.bway.net (sdsl-216-220-103-156.dsl.bway.net [216.220.103.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTP id 91ADB2BAB41; Tue, 3 Mar 2009 00:16:55 -0500 (EST) Cc: Richard Sandiford , Olivier Hainque , gcc-patches Message-Id: <9BE4A356-85F8-4C92-8367-230A048C02B6@adacore.com> From: Geert Bosch To: Laurent GUERBY In-Reply-To: <1236030367.11347.846.camel@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips Date: Tue, 03 Mar 2009 05:17:00 -0000 References: <20071008085929.GA31575@cardhu.act-europe.fr> <87ir5ggirc.fsf@firetop.home> <87ve9ff96r.fsf@firetop.home> <7C2C6C26-1CF3-4304-B9E3-A33DA1C7B2C6@adacore.com> <1236015011.11347.800.camel@localhost> <873advn0uy.fsf@firetop.home> <1236030367.11347.846.camel@localhost> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-03/txt/msg00132.txt.bz2 On Mar 2, 2009, at 16:46, Laurent GUERBY wrote: > I'm waiting a bit to see if AdaCore people did find a solution, if not > I'll investigate. As discussed in the old thread we don't really > want 128 bit Long_Long_Float anyway if not supported in hardware. > > For reference, below ACATS log extract of the failing tests, > some of it is self-explanatory. To me most of the stuff seem > to be that 128 bit float software routines might just not be accurate > enough. The Ada standard requires support for the widest hardware floating point format provided by the hardware. This type can be accessed by declaring your type as "type My_Float is digits System.Max_Digits". Various routines for printing and type conversions use this type as well. Ada does not allow a "type My_Float is digits X" where X > System.Max_Digits, except in some special cases where the type would provide more accuracy but a restricted range. For that reason, we can't easily support a 128-bit Long_Long_Float. The way forward would be to dynamically build a table of all available types, find out essential properties (basic arithmetic supported in hardware or not, implicit extra precision (a la x87) or not, fused multiply-add or not) and use that for type selection. Some work in this direction has been done in Gigi, but to add support for all parts of the compiler, especially the required exact static (compile-time) evaluation of expressions and such, is quite hard and involves a serious chunk of development work. So, even if "long long double" is 128 bits, Long_Long_Float not be wider than WIDEST_HARDWARE_FP_SIZE. -Geert