[PATCH] Returns NaN for sqrt with negative fp argument

[Jiangning Liu]

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
http://en.wikipedia.org/wiki/IEEE_floating_point

    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?

Thanks,
-Jiangning


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