On Mon, 5 Dec 2016 18:50:39 +0000
Joseph Myers <joseph@codesourcery.com> 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:
> > >   
> > > 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/?

When building from sysdeps (e.g. sysdeps/ieee754/ldbl-opt/w_acosl.c),
the command that is used to build it, puts <build_dir>/math first in
the include search path:

gcc ../sysdeps/ieee754/ldbl-opt/w_acosl.c [...] -I../include
-I/home/gftg/build/glibc/math  -I/home/gftg/build/glibc
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64le/fpu [...]

And that will make sysdeps files try to use the new, auto-generated
wrappers:

In file included from /home/gftg/build/glibc/math/w_acosl.c:2:0,
                 from ../sysdeps/ieee754/ldbl-opt/w_acosl.c:4:
./w_acos_template.c:1:2: error: #error 

Is that what you expected?
Is it OK to have <build_dir>/math be searched first for include files?

> 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.

For this first part.. this is independent of the other patches, right?
Is the attached patch in the lines of what you had in mind?
(I just wrote it for log1p, because I still don't know what to do about
scalbln (I think I can't use declare_mgen_alias because w_scalbln
doesn't create a strong alias).  Besides, I still don't know how to
deal with the IS_IN (libm) test in
sysdeps/ieee754/ldbl-64-128/w_scalblnl.c)

Gabriel