From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16296 invoked by alias); 31 Jul 2017 20:43:26 -0000 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 Received: (qmail 16278 invoked by uid 89); 31 Jul 2017 20:43:25 -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=practically, cooperating 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 ESMTP; Mon, 31 Jul 2017 20:43:23 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1dcHX5-0006cx-Ip from joseph_myers@mentor.com ; Mon, 31 Jul 2017 13:43:19 -0700 Received: from digraph.polyomino.org.uk (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 31 Jul 2017 21:43:16 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1dcHWw-0003VX-Q6; Mon, 31 Jul 2017 20:43:10 +0000 Date: Mon, 31 Jul 2017 20:43:00 -0000 From: Joseph Myers To: Michael Meissner CC: GCC Patches , Segher Boessenkool , David Edelsohn , Bill Schmidt Subject: Re: [PATCH, RFC] Proposed PowerPC IEEE 128-bit floating point changes In-Reply-To: <20170721191757.GA11603@ibm-tiger.the-meissners.org> Message-ID: References: <20170721191757.GA11603@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-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-07/txt/msg02073.txt.bz2 On Fri, 21 Jul 2017, Michael Meissner wrote: > The first change is to enable the C language to use _Float128 keyword (but not > __float128) without having to use the -mfloat128 option on power7-power9 > systems. My question is in the TR that introduced _Float128, is there any > expectation that outside of the built-in functions we already provide, that we > need to provide runtime functions? Yes, glibc 2.26 will be coming along > shortly, and it should provide most/all of the F128 functions, but distros > won't pick this library up for some time. In formal standards terms, TS 18661-3 builds on TS 18661-1 (for binary floating point) or 18661-2 (for decimal floating point), both of which add the contents of , and the numeric conversion functions from to the library features required of freestanding implementations. I don't think that makes any difference to what GCC should do, however. Just as stdatomic.h is provided by GCC, though strictly a hosted library feature rather than one required of freestanding implementations, and just as GCC always requires a C library to provide memcpy / memmove / memset, even the case of a freestanding implementation requires a cooperating compiler / library pair, and in this case it makes the most sense for those library facilities (both C11 ones and newer TS 18661 ones such as for float128) to come from an external libc/libm. At some point I should update standards.texi to discuss these variations from the old rule of thumb of GCC providing exactly those library facilities required of freestanding implementations. Practically, code expecting compiler support for _Float128 to imply library support is just like code expecting __STDC_VERSION__ to imply C11 library support; people may write such code, but it's not practically portable. -- Joseph S. Myers joseph@codesourcery.com