Re: [PATCH v2 1/3] Cleanup __ieee754_sqrt(f/l)

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 21 Dec 2017, Wilco Dijkstra wrote:

> Joseph Myers wrote:
> 
> > It's not being defined, it's being 1 rather than 0 (#if, not #ifdef).  
> > You should use _Float128, not __float128; bits/floatn.h handles defining 
> > _Float128 as a typedef if necessary for older compilers.
> 
> OK I can get that to work, but I still get odd issues with sqrtf128 being
> called from the testsuite, while libm.so only defines __sqrtf128, so it
> gives undefined symbol errors on x64. So I wonder whether in external
> headers we should never do this:
> 
> #define sqrtl sqrtf128

float128_private.h isn't an external header.  It includes math.h and other 
headers, then redefines symbols from them, and is included before the main 
implementation of a float128 function.  Naturally your problem needs 
debugging, since of course libm should be exporting sqrtf128.  (And 
float128_private.h shouldn't be included at all when the type-generic 
wrappers are, so shouldn't have any opportunity to cause trouble with the 
automatically generated w_sqrtf128 which is what ought to be defining 
sqrtf128 as an alias to __sqrtf128.)

> Unless there is an easy fix for these issues, I can't see any point in
> including it in my current patches - improving float/double inlining in this
> release gives much more benefit to all targets.

Using sqrt consistently for float / double means changing the M_SQRT 
definition, which means sqrtf128 gets used as well, which means you need 
to do something for sqrtf128 simply to avoid localplt failures on 
non-POWER9 systems with distinct float128, which clearly indicates 
handling all types consistently.

-- 
Joseph S. Myers
joseph@codesourcery.com