This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/8] float128: Add wrappers for IEEE functions.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Gabriel F. T. Gomes" <gftg at linux dot vnet dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 5 Dec 2016 18:50:39 +0000
- Subject: Re: [PATCH 3/8] float128: Add wrappers for IEEE functions.
- Authentication-results: sourceware.org; auth=none
- References: <1478716859-3246-1-git-send-email-gftg@linux.vnet.ibm.com> <1478716859-3246-4-git-send-email-gftg@linux.vnet.ibm.com> <alpine.DEB.2.20.1611092132390.6428@digraph.polyomino.org.uk> <20161205144754.4c0c7c13@keller.br.ibm.com>
On Mon, 5 Dec 2016, Gabriel F. T. Gomes wrote:
> On Wed, 9 Nov 2016 21:38:07 +0000
> Joseph Myers <joseph@codesourcery.com> wrote:
>
> > On Wed, 9 Nov 2016, Gabriel F. T. Gomes wrote:
> >
> > > From: "Paul E. Murphy" <murphyp@linux.vnet.ibm.com>
> > >
> > > 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 <builddir>/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-<type>.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