<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>No problem, thanks for the simple report.</div><div><br></div><div>– Steve</div><br><div><div>On Jun 8, 2014, at 4:09 PM, <a href="mailto:victor.zverovich@gmail.com">victor.zverovich@gmail.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Thanks for fixing this.<div><br></div><div>- Victor</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 7, 2014 at 11:11 PM, Steve (Numerics) Canon <span dir="ltr"><<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Jun 6, 2014, at 2:36 PM, Stephen Canon <<a href="mailto:scanon@apple.com">scanon@apple.com</a>> wrote:<br>
<br>
>> On Jun 6, 2014, at 2:18 PM, Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br>
>><br>
>> On 06/06/2014 01:02 PM, Chandler Carruth wrote:<br>
>>><br>
>>> The standards for C and C++, and consequentially Clang and LLVM, are terribly underspecified w.r.t. things like NaN behavior. =/ We have seen this before, and even if we fix it in Clang/LLVM I worry that it will regress as there are many places where we model NaNs in a manner slightly too aggressive to be strictly IEEE-754 conforming. =[<br>
>> Is being IEEE-754 conforming a worthwhile goal? If so, we could talk about how to improve testing to prevent such regressions and find other latent bugs.<br>
>><br>
>> I would generally argue in favour of conformance, but am not familiar with exactly what the C/C++ rules are.<br>
><br>
> C and C++ recommend but do not require IEEE-754 conformance (they define a means for a platform to claim conformance, but do not require that it do so). At least within Apple, we’ve historically put a fair bit of effort into maintaining IEEE-754 conformance, at least when it comes to the semantics of basic arithmetic in default rounding (like this case does).<br>
><br>
>> To say this differently, are there important optimizations we don't want to loose which aren't conforming?<br>
><br>
> We have relaxed modes (-ffast-math and friends) that license those optimizations. The default mode should conform as much as reasonably possible.<br>
<br>
</div></div>This turns out to be a bug in APFloat. I'll post a patch to llvm-commits in a minute.<br>
<div class="HOEnZb"><div class="h5"><br>
– Steve<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></body></html>