On 17/12/14 00:04, Joseph Myers wrote:
On Mon, 15 Dec 2014, James Greenhalgh wrote:

@@ -22792,6 +22792,12 @@ vsqrtq_f32 (float32x4_t a)
    return __builtin_aarch64_sqrtv4sf (a);
  }
+__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
+vsqrt_f64 (float64x1_t a)
+{
+  return (float64x1_t) { __builtin_sqrt (a[0]) };
+}
Hi Kyrill,

Does this introduce an implicit need to link against a maths library if
we want arm_neon.h to work correctly? If so, I think we need to take a
different approach.

At O0 I've started to see:

   " undefined reference to `sqrt' "

When checking a large arm_neon.h testcase.

It does seem strange that the mid-end would convert a __builtin_sqrt back
to a library call at O0 when the target has an optab for it, so perhaps
there is a bug there to go hunt?
__builtin_sqrt has the same semantics as the sqrt library function.  This
includes setting errno for negative arguments (other than -0 and -NaN).
The semantics also include that it's always OK to expand to a call to that
library function (generally, __builtin_foo may always expand to a call to
foo, if there is such a library function).

Thanks for the explanation.
I see that there are some intrinsics implemented in terms of __builtin_fabsf, presumable they can be at 'risk' too of having a library call emitted?

Kyrill




Reply via email to