From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110307 invoked by alias); 21 Jun 2016 15:38:52 -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 110285 invoked by uid 89); 21 Jun 2016 15:38:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=IFmode, ifmode, sk:ieee128, kfmode 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 15:38:41 +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 1bFNl6-0002Vm-5E from joseph_myers@mentor.com ; Tue, 21 Jun 2016 08:38:36 -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 16:38:34 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1bFNl3-0000Be-8p; Tue, 21 Jun 2016 15:38:33 +0000 Date: Tue, 21 Jun 2016 15:38:00 -0000 From: Joseph Myers To: FX CC: , , , , , , , , , , , Subject: Re: Implement C _FloatN, _FloatNx types In-Reply-To: Message-ID: References: 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/msg00071.txt.bz2 On Tue, 21 Jun 2016, FX wrote: > > Fortran note: I took the conservative approach of renaming the > > float128_type_node used in the Fortran front end, since I wasn't sure > > if it's safe to make the front end always use the language-independent > > node (which follows C rules - thus, being distinct from long double > > even if that has binary128 format). > > In the Fortran front-end, float128_type_node is defined as the > (expectedly unique) floating-point type for which mode_precision is > equal to 128 but not equal to LONG_DOUBLE_TYPE_SIZE. That is, it is > garanteed that float128_type_node is not long_double_type_node. > > If fact, if there is a long double type with precision of 128, then > float128_type_node is NULL. > > Would that match the (new) C behavior? I think it does. Precision is a poorly defined concept in this context. Precision of a type is meant to be the number of value bits, which is 128 not just for binary128 but also for IBM long double. I think the same applies to precision of a mode. See Richard's comments in on how the use of fractional float modes for IFmode and KFmode is a lie, because those modes both have 128 significant bits, not 106 and 113. To avoid the misleading mode precision values becoming misleading type precision values, my patch includes a workaround in build_common_tree_nodes to give precedence to the N in binaryN (although it occurs to me that this is not in fact a sufficient workaround, because _Float64x needs such a fix as well) - that keeps _Float128 having type precision 128 in that case, like ieee128_float_type_node in the PowerPC back end does. Language-independent float128_type_node has the following properties: it is always of binary128 format, never of another format that might have precision 128 (such as IBM long double). If binary128 is supported, float128_type_node is non-NULL, whether or not long double also has precision 128. That does not seem to match your semantics for Fortran in the case where long double is binary128, as for Fortran you'd have NULL but the language-independent node would be a distinct type from long double, not NULL. -- Joseph S. Myers joseph@codesourcery.com