<div dir="ltr">Hi Tim,<div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-10 14:17 GMT+08:00 Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Jiangning,<br>
<div class=""><br>
On 10 June 2014 02:45, Jiangning Liu <<a href="mailto:liujiangning1@gmail.com">liujiangning1@gmail.com</a>> wrote:<br>
> IEEE-754 standard requires to return NaN for sqrt with negative fp value<br>
> argument, while llvm now is returning fp zero instead. This patch is to fix<br>
> this issue and spec2006/483.xanlancbmk can pass with -ffast-math for AArch64<br>
> target, but the fix itself is a general one rather than target specific.<br>
<br>
</div>This sounds like an expected consequence of -ffast-math. The language<br>
reference specifically says that using @llvm.sqrt on negative numbers<br>
is undefined, and indeed that intrinsic call is only formed from sqrtf<br>
in -ffast-math mode.<br></blockquote><div><br></div>LLVM IR language spec says,<br><br>    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).<br>
<br>But obviously right now LLVM is returning fp zero covering -0.0, right?<br><br>Also, wikipedia says below at <a href="http://en.wikipedia.org/wiki/IEEE_floating_point">http://en.wikipedia.org/wiki/IEEE_floating_point</a> <br>
<br>    Invalid operation (e.g., square root of a negative number) (returns qNaN by default).<br><br>I don't have IEEE-754 spec at hand, and I'm assuming this is de facto implementation standard.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><br>
> Also, sqrt in glibc behaves like this, and clang is defining __GNUC__, so it<br>
> means we need to keep compatibility with GCC around this as well.<br>
<br>
</div>I don't find that compelling, either. Particularly when -ffast-math is<br>
involved, we shouldn't be expected to replicate the precise points<br>
where GCC decides to ignore NaNs and how it does so.<br></blockquote><div><br></div><div>I'm fine with this, but it's harmless to follow the same "undefined" behavior even with -ffast-math enabled, right?</div>
<div><br></div><div>Or vice versa, why is fp zero a more reasonable implementation than NaN for this case?</div><div><br></div><div>Thanks,</div><div>-Jiangning</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
Cheers.<br>
<span class=""><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>