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

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Mon, 2016-12-05 at 18:50 +0000, Joseph Myers wrote:
> 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.
> 
Are these changes really necessary at this time? 

I appropriate your desire to get a jump on the emerging standards but
the associates changes are a constant churn on the code base and impacts
our work.

Deferring the C17 work (and associated restructuring) until 2.26 will
expedite enabling our base _Float128 support in time for 2.25.