RE: generic fabs implementation

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 18 May 2015, Wilco Dijkstra wrote:

> Given GLIBC can now rely on a modern GCC for its build, can we avoid
> this and actually use the builtins rather than having each target
> override the generic implementation with an inline assembler version?
> 
> double
>  __fabs (double x)
>  {
> -  u_int32_t high;
> -  GET_HIGH_WORD (high, x);
> -  SET_HIGH_WORD (x, high & 0x7fffffff);
> -  return x;
> +  return __builtin_fabs (x);
>  }
> 
> GCC will always inline __builtin_fabs, with -O0, -Os and -fno-builtin.

I believe doing this is safe (in that a proper inline expansion will be 
generated, by bit-fiddling if needed) *except for the ldbl-128ibm version 
of fabsl* (where fabs isn't simply a matter of clearing one bit, and GCC 
doesn't know how to do it correctly inline for soft-float / e500 - see GCC 
bug 29253 and the corresponding -fno-builtin-fabsl in 
sysdeps/powerpc/nofpu/Makefile).

However, there might be cases where GCC generates calls to an 
absolute-value instruction that fails to clear the sign bit of a NaN, or 
predates IEEE 754-2008 and raises "invalid" for a signaling NaN.  At least 
the former would be a clear GCC bug (on MIPS, for example, GCC makes sure 
to avoid abs instructions unless -mabs=2008 or -ffinite-math-only, for 
that reason), but it's something to watch out for.

-- 
Joseph S. Myers
joseph@codesourcery.com