From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5432 invoked by alias); 5 Dec 2016 18:51:00 -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 5413 invoked by uid 89); 5 Dec 2016 18:50:59 -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=Gabriel, gabriel, murphy, among X-HELO: relay1.mentorg.com Date: Mon, 05 Dec 2016 18:51:00 -0000 From: Joseph Myers To: "Gabriel F. T. Gomes" CC: Subject: Re: [PATCH 3/8] float128: Add wrappers for IEEE functions. In-Reply-To: <20161205144754.4c0c7c13@keller.br.ibm.com> Message-ID: References: <1478716859-3246-1-git-send-email-gftg@linux.vnet.ibm.com> <1478716859-3246-4-git-send-email-gftg@linux.vnet.ibm.com> <20161205144754.4c0c7c13@keller.br.ibm.com> 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: 2016-12/txt/msg00115.txt.bz2 On Mon, 5 Dec 2016, Gabriel F. T. Gomes wrote: > On Wed, 9 Nov 2016 21:38:07 +0000 > Joseph Myers wrote: > > > On Wed, 9 Nov 2016, Gabriel F. T. Gomes wrote: > > > > > From: "Paul E. Murphy" > > > > > > These are copied from the long double version. posix style > > > errors are assumed, and inlined. Where a function is not > > > defined by TS 18661-3, the wrapper is not implemented. > > > > I don't think float128-specific wrappers like this are appropriate. All > > these wrappers should be type-generic. If you put type-generic wrappers > > as math/w_*_template.c, will the existing wrappers with matherr support > > still take precedence for existing types? > > They won't. > > The files generated for the functions listed in gen-libm-calls > (in /math/) are always generated, regardless of the existence > of the same file in the source dir. And the generated-files take > precedence over the files in the source dir. > > Do you have any suggestions on how to proceed? Source files in sysdeps certainly take precedence; that's by design, so that architectures can easily have their own implementations that override the templates. Are you saying that this only works for source files in sysdeps and not for those in math/? If so, then the existing log1p and scalbln wrappers should just be made into type-generic templates like I did with ilogb; there is nothing in those wrappers using the _LIB_VERSION / matherr / __kernel_standard functionality that we want to obsolete and so don't want to form part of the interface to new functions. For the rest of the existing wrappers, this indicates more of the steps towards deprecation are needed as part of adding the new wrappers. There are I think three classes per-floating-point-format function implementations built in math/ (here I am specifically discussing per-format implementations that are built, a related but different topic from the per-type public APIs that are exported which we have discussed before when considering what APIs to expose for float128). (a) Function implementations that should be built for all floating-point formats supported by glibc. (b) Function implementations that should be built for formats that may be used for float, double or long double, but not for formats not supported for any of those types. Right now, the distinction from (c) below does not matter, but if in future there is support for float128 as an alternative long double format on powerpc64le, then functions such as scalb and significand will fall in class (b) because scalbl and significandl, as existing APIs, will need supporting for the new choice of long double (but there should still be no public scalbf128 or significandf128 APIs, just internal names that the scalbl and significandl APIs get mapped to by the headers). (c) Function implementations that should only be built for float, double and long double - that is, for the formats historically supported for those, not for any format added in future. Right now (c) only has the k_standard and w_lgamma_compat functions listed in libm-compat-calls. But obsoleting matherr etc. (or preparing for that obsoletion) would mean rather more functions go there - meaning libm-compat-calls should probably start being defined in a way that doesn't involve mentioning each function three times. Specifically: the existing wrappers (except those that don't use _LIB_VERSION, __kernel_standard etc. and can just be made type-generic if they aren't already) would be renamed, say w_fooF to w_fooF_compat (_compat2 in the lgamma case where _compat already exists). The _compat names would end up in the new version of libm-compat-calls, with the old names being removed from libm-calls. New type-generic templates would be added to gen-libm-calls. The templates would all have some #if conditional (using macros from math-type-macros-.h) meaning "don't build this for float, double or long double; do build this for any other formats". That would mean they are initially used only for float128. Actual obsoletion of the old wrappers (which might come later) would involve, among other changes, changing the conditional to say "don't build for float, double or long double unless !SHLIB_COMPAT (something)", i.e. build for static libm and for new ports but not otherwise (unless we decide to give all libm functions using the wrappers new symbol versions [*]), with the compat wrappers having corresponding SHLIB_COMPAT conditionals added so they aren't built for static libm or new ports. Note that it's quite likely new wrappers would expose more bugs in the __ieee754_* functions, where those functions return a bad value in an error case but __kernel_standard hides that by changing the return value to the correct one. [*] Adding support for *f32, *f64 etc. names as aliases for existing functions would also mean considering whether to alias the old wrappers (fairly harmless once _LIB_VERSION is a compat symbol so any link to the new names can't use it anyway) or to build the new wrappers in order to export them under those names. -- Joseph S. Myers joseph@codesourcery.com