Re: [PATCH 3/8] float128: Add wrappers for IEEE functions.

[Joseph Myers <joseph at codesourcery dot 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