From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84693 invoked by alias); 21 Jun 2016 21:18:50 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 84663 invoked by uid 89); 21 Jun 2016 21:18:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=infinities, __float80, TARGET_FLOAT128, nans X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 21 Jun 2016 21:18:38 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1bFT46-0005r2-Mo from joseph_myers@mentor.com ; Tue, 21 Jun 2016 14:18:35 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Tue, 21 Jun 2016 22:18:33 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1bFT43-0006s0-Sd; Tue, 21 Jun 2016 21:18:31 +0000 Date: Tue, 21 Jun 2016 21:18:00 -0000 From: Joseph Myers To: Michael Meissner CC: , , , , , , , , , , , Bill Schmidt , Steve Munroe Subject: Re: Implement C _FloatN, _FloatNx types [version 2] In-Reply-To: <20160621205302.GA8544@ibm-tiger.the-meissners.org> Message-ID: References: <20160621205302.GA8544@ibm-tiger.the-meissners.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-06/txt/msg00079.txt.bz2 On Tue, 21 Jun 2016, Michael Meissner wrote: > While from one perspective, it would have been cleaner if the PowerPC > had separate internal types for IBM extended double and IEEE 128-bit floating > point. But the way the compiler has been implemented is that TFmode is which > ever type is the default. Typically, in the Linux environment, this is IBM > extended double, but we are hoping in the future to change the default to make > long double IEEE 128-bit. So, I think we need to do something like: > > static machine_mode > rs6000_floatn_mode (int n, bool extended) > { > if (extended) > { > switch (n) > { > case 32: > return DFmode; > > case 64: > if (TARGET_FLOAT128) > return (TARGET_IEEEQUAD) ? TFmode : KFmode; That's essentially what I had in the first patch version. I.e., you and Bill are making contradictory statements about whether always to use KFmode (in which case *q constants should be fixed to match) or whether to prefer TFmode when it's binary128 (in which case no fixes beyond my patch (with the first version of this function) are needed as my patch will make __float128 into an alias for _Float128, which will prefer TFmode when it's binary128). > As an aside, one of the issues, I'm currently grappling with is how to enable > the __float128 machinery without enabling the __float128 keyword (PR 70589). > The reason is we need to create the various built-in functions for IEEE 128-bit > functions, which means creating the type and keyword support. Perhaps it would be best not to allow __float128 to be disabled? I.e. have it always available for 64-bit and never available for 32-bit (or something like that). Or at least don't allow it to change during the source file. Because we want these functions to end up in generic code rather than target-specific. And at least the C-family built-ins machinery handles not creating a built-in function if its type would be error_mark_node, and using error_mark_node for types derived from error_mark_node. That is, if in the generic code we have DEF_PRIMITIVE_TYPE (BT_FLOAT128, float128_type_node ? float_128_type_node : error_mark_node) in builtin-types.def, then it should be possible to list all the relevant functions in builtins.def and have them only created when the type is enabled. But you'll run into problems if there are conditions for function availability changing part way through the source file.... (There's existing machinery for targets to change built-in function availability part way through the source file, but it seems likely to be nasty to apply that to target-independent functions.) > Another thing that I'm grappling with is how to identify when the floating > point emulation functions have been built. Right now, it is only built for > 64-bit Linux systems, and it is not built for AIX, BSD, or the various 32-bit > embedded targets. See the libgcc_floating_mode_supported_p hook. (It doesn't do much, and you might need to implement it for your target, but it's the right idea.) > However, I suspect that in the future, we may have users that want to do > arithmetic in this format (particularly vectors). This comes from people > wanting to interface with attached GPUs that often times support HFmode, and > with machine learning systems that does not need the precision. So, we should > at least think what is needed to enable HFmode as a real type. Basically, you need to define an ABI, and you need changes to excess precision support which is currently geared to the x87 case. > > GCC has some prior support for nonstandard floating-point types in the > > form of __float80 and __float128. Where these were previously types > > distinct from long double, they are made by this patch into aliases > > for _Float64x / _Float128 if those types have the required properties. > > And of course other machine dependent non-standard floating point types > such as IBM extended double. Which cannot be _FloatN / _FloatNx types; those names are strictly for types with IEEE semantics (and representation, in the _FloatN case). float, double and long double are much more flexible about possible formats than _FloatN and _FloatNx. > In addition, there is the question of what to do on the embedded machines that > might use IEEE format for floating point, but does not support all of the > features in IEEE 754R such as NaNs, infinities, de-normal numbers, negative 0, > etc. Those also cannot be _FloatN / _FloatNx types. Note how my real.c changes mark spu_single_format as not suitable for such a type. -- Joseph S. Myers joseph@codesourcery.com