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

[Joseph Myers <joseph@codesourcery.com>]

On Wed, 7 Dec 2016, Gabriel F. T. Gomes wrote:

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

Well, the detailed design is Paul's; I don't know if he considered the 
case of wanting a non-type-generic file in math/ to override a 
type-generic one.

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

It looks like there are two possible issues involved.

(a) Which .c file gets built if there aren't any in sysdeps?  Is it the 
one in math/ in the source directory, or the one generated in the build 
directory?

(b) When sysdeps files do a #include of w_* files, where do those 
#included files come from?

Your command line shows a problem with (b): because of the -I of the 
*top-level* build directory (not that of the math/ subdirectory), 
"#include <math/w_acosl.c>" wrongly includes the generated file.

In my previous comments I was thinking of (a).  But it doesn't really 
matter, as renaming the existing files like I suggested (and updating the 
#includes of them) would solve both issues.  (Moving them into 
sysdeps/generic without renaming would probably also do the trick, but 
that's uglier and I don't think it's really any easier since you still 
need to update the #includes wherever you move them.)

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

For scalbln, look at math/s_ldexp_template.c and the ldbl-opt s_ldexp* 
files for an example - the issues are pretty similar.

For log1p, I'd expect the template file to use -1 (or M_LIT (-1.0) in the 
islessequal call) rather than the double value -1.0.  And I'd hope that 
you can remove the ldbl-128ibm/w_log1pl.c and ldbl-64-128/w_log1pl.c files 
completely and the generated file will do the right thing automatically.

-- 
Joseph S. Myers
joseph@codesourcery.com