This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]