<div dir="ltr">Tim,<div><br></div><div class="gmail_extra"><div class="gmail_quote"><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>> Or vice versa, why is fp zero a more reasonable implementation than NaN for<br>
> this case?<br>
<br>
</div>I'd say the best implementation would be undef (possibly even<br>
reporting a warning, though that's strictly QoI and probably better as<br>
a sanitizer anyway). I'm not sure why 0.0 is there at the moment<br>
though.<br></blockquote><div><br></div>I think now I understand this a little bit. Following LLVM IR spec, when using -ffast-math, -menable-no-nans are -menable-unsafe-fp-math enabled, and this sounds reasonable to retain defined/stable/safe behavior, so we can't return NaN, then 0.0 is a choice.</div>
<div class="gmail_quote"><br>Thanks,<br>-Jiangning<div> </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><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div>