From: Joseph Myers <joseph@codesourcery.com>
To: "Gabriel F. T. Gomes" <gftg@linux.vnet.ibm.com>
Cc: <libc-alpha@sourceware.org>
Subject: Re: [PATCH 3/8] float128: Add wrappers for IEEE functions.
Date: Mon, 05 Dec 2016 18:51:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1612051829010.19059@digraph.polyomino.org.uk> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2016-12-05 18:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 18:41 [PATCH 0/8] More float128 declarations Gabriel F. T. Gomes
2016-11-09 18:41 ` [PATCH 6/8] float128: Expose _Float128 finite math functions Gabriel F. T. Gomes
2016-11-09 22:06 ` Joseph Myers
2017-03-03 20:17 ` Gabriel F. T. Gomes
2017-03-03 20:50 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 3/8] float128: Add wrappers for IEEE functions Gabriel F. T. Gomes
2016-11-09 21:38 ` Joseph Myers
2016-12-05 16:48 ` Gabriel F. T. Gomes
2016-12-05 18:51 ` Joseph Myers [this message]
2016-12-05 22:52 ` Steven Munroe
2016-12-06 0:31 ` Joseph Myers
2016-12-06 2:39 ` Steven Munroe
2016-12-07 19:36 ` Gabriel F. T. Gomes
2016-12-07 21:47 ` Joseph Myers
2016-12-09 21:24 ` Gabriel F. T. Gomes
2016-12-14 0:47 ` Joseph Myers
2016-12-14 13:36 ` Gabriel F. T. Gomes
2016-12-14 14:33 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 4/8] Add support for testing __STDC_WANT_IEC_60559_TYPES_EXT__ Gabriel F. T. Gomes
2016-11-09 21:42 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 1/8] ldbl-128: Use mathx_hidden_def inplace of hidden_def Gabriel F. T. Gomes
2016-11-09 18:41 ` [PATCH 2/8] float128: Add _Float128 make bits to libm Gabriel F. T. Gomes
2016-12-09 21:23 ` Tulio Magno Quites Machado Filho
2016-12-12 22:49 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 8/8] float128: Add wrappers to override ldbl-128 as float128 Gabriel F. T. Gomes
2016-11-09 22:13 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 7/8] float128: Add private _Float128 declarations for libm Gabriel F. T. Gomes
2016-11-09 22:08 ` Joseph Myers
2016-11-10 22:13 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 5/8] float128: Add public _Float128 declarations to libm Gabriel F. T. Gomes
2016-11-09 22:04 ` Joseph Myers
2016-11-09 21:31 ` [PATCH 0/8] More float128 declarations Joseph Myers
2016-11-09 23:52 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1612051829010.19059@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gftg@linux.vnet.ibm.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).