From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70595 invoked by alias); 6 Dec 2017 17:45:26 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 70372 invoked by uid 89); 6 Dec 2017 17:45:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=allowance, reserved X-HELO: relay1.mentorg.com Date: Wed, 06 Dec 2017 17:45:00 -0000 From: Joseph Myers To: Subject: RFC: TS 18661-4 floating-point interfaces Message-ID: 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-03.mgc.mentorg.com (139.181.222.3) X-SW-Source: 2017-12/txt/msg00174.txt.bz2 ISO/IEC TS 18661-4:2015 provides C interfaces for additional floating-point operations, mostly from IEEE 754-2008 plus a few additions to those. Building on the provisional consensus from the discussion starting at , and similarly to the proposals for TS 18661-1 and TS 18661-3 , I'd like to propose we consider these interfaces appropriate for glibc, as follows (which is simpler than the previous proposals because this part of the TS only adds functions, not constants or types). I don't expect to implement any of this for glibc 2.27 (I expect to work on the missing 18661-1 and 18661-3 pieces first). These features are expected to be proposed for inclusion as optional features in C2x (it's only parts 1 and 2 of TS 18661 that are definitely intended to be included in C2x, but parts 3, 4 and 5 should at least be proposed and considered). The TS adds the following functions for each supported floating-point type. The proposal is only for these functions, not for anything involving decimal floating point, or for the reserved cr* names for correctly-rounded functions, or for the reserved c* names for corresponding complex functions. exp2m1 exp10[*] exp10m1 logp1[**] log2p1 log10p1 rsqrt compoundn rootn pown powr acospi asinpi atanpi atan2pi cospi sinpi tanpi reduc_sum reduc_sumabs reduc_subsq reduc_sumprod scaled_prod scaled_prodsum scaled_proddiff [*] Already in glibc. [**] Alias of log1p. Except for reduc_* and scaled_prod* there are also corresponding type-generic macros in . (glibc has the exp10 functions but not a corresponding type-generic macro.) All these functions would be defined in libm (including aliases where multiple types have the same ABI.) As usual, when a function is added it would be added for all supported floating-point types at the same time (and the aliases would be automatic from the use of the common alias macros). In some cases it's likely simple type-generic template versions would be used that implement the functions in terms of other functions already in libm, with the option for faster and more accurate versions for particular types to be added later should someone wish to implement them. Entries would be added to math/Versions, for all types together, notwithstanding that only some glibc configurations support _Float128 or _Float64x. There would be no need to make any special allowance for the possibility of some glibc configuration adding support for new types or long double formats in future; if any configuration does make such a change in future, part of that change would be ensuring it handles all new libm functions properly (just as ldbl-opt does not have Versions entries for libm functions added since 2.4 and so there would be extra work to do for any configuration with long double = double that decides in future to add wider long double support). However, just as with other libm functions, there would be libnldbl.a wrappers in ldbl-opt (for compilers with 64-bit long double and no __REDIRECT support) unless we've officially ceased to support compilers with no __REDIRECT support for using glibc and so removed libnldbl.a. All the usual test and documentation requirements apply for these functions. In the absence of MPFR support for some of the above functions, such support would need to be added locally in gen-auto-libm-tests (but if present only in a development version of MPFR it would be reasonable for gen-auto-libm-tests to depend on such a development version; it already depends on a development version of MPC for a bug fix not in any released version). Any comments on this proposal? -- Joseph S. Myers joseph@codesourcery.com