[PATCH] Returns NaN for sqrt with negative fp argument

Jiangning Liu liujiangning1 at gmail.com
Tue Jun 10 00:45:31 PDT 2014

Hi Tim,

2014-06-10 14:17 GMT+08:00 Tim Northover <t.p.northover at gmail.com>:

> Hi Jiangning,
> On 10 June 2014 02:45, Jiangning Liu <liujiangning1 at gmail.com> wrote:
> > IEEE-754 standard requires to return NaN for sqrt with negative fp value
> > argument, while llvm now is returning fp zero instead. This patch is to
> fix
> > this issue and spec2006/483.xanlancbmk can pass with -ffast-math for
> AArch64
> > target, but the fix itself is a general one rather than target specific.
> This sounds like an expected consequence of -ffast-math. The language
> reference specifically says that using @llvm.sqrt on negative numbers
> is undefined, and indeed that intrinsic call is only formed from sqrtf
> in -ffast-math mode.

LLVM IR language spec says,

    llvm.sqrt has undefined behavior for negative numbers other than -0.0
(which allows for better optimization, because there is no need to worry
about errno being set).

But obviously right now LLVM is returning fp zero covering -0.0, right?

Also, wikipedia says below at

    Invalid operation (e.g., square root of a negative number) (returns
qNaN by default).

I don't have IEEE-754 spec at hand, and I'm assuming this is de facto
implementation standard.

> > Also, sqrt in glibc behaves like this, and clang is defining __GNUC__,
> so it
> > means we need to keep compatibility with GCC around this as well.
> I don't find that compelling, either. Particularly when -ffast-math is
> involved, we shouldn't be expected to replicate the precise points
> where GCC decides to ignore NaNs and how it does so.

I'm fine with this, but it's harmless to follow the same "undefined"
behavior even with -ffast-math enabled, right?

Or vice versa, why is fp zero a more reasonable implementation than NaN for
this case?


> Cheers.
> Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140610/5324e02e/attachment.html>

More information about the llvm-commits mailing list