This is the mail archive of the
mailing list for the glibc project.
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 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