I don't think we can rely on VFP hardware being available. It is at least theoretically possible to build a kernel using "nooptions VFP" and build all of userland with --float-abi=soft and any use of a vfp instruction will be a SIGILL, right?

Given that fabs() will invoke the clang builtin codegen unless something has specifically disabled that (and clang knows whether to generate vfp insns or not), would a viable fix for this should-never-be-called function be something like the following?

double
fabs(double x)
{

if (x == 0)
  return 0;
else if (x < 0)
  return -x;
else
  return x;

}

In D13131#288739, @ian wrote:

I don't think we can rely on VFP hardware being available. It is at least theoretically possible to build a kernel using "nooptions VFP" and build all of userland with --float-abi=soft and any use of a vfp instruction will be a SIGILL, right?

In softfloat mode __builtin_fabs() will just perform a bitwise and to remove the sign bit which will avoid depending on FP being available.
I made the change to use __builtin_fabs() for MIPS in D13135 and now we have the libc++ tests passing on MIPS softfloat as well.

As usual, the clang/llvm documentation ranges from murky to non-existant on this stuff. I did track down in the gcc docs that you can always explicitly call __builtin_foo() even when -fno-builtin and -ffreestanding are in effect (such as when we build libstand and loader(8)). Since clang tries to be gcc compatible, I guess we have to assume it will behave the same.

That being the case, I agree that the solution used for mips, that is, the implementation of fabs(x) is {return __builtin_fabs(x);}, seems exactly right.