<div dir="ltr">On Wed, Jun 19, 2013 at 11:12 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">----- Original Message -----<br>
><br>
><br>
><br>
> The function rint() is supposed to round to the nearest integer,<br>
> breaking ties to even. With -ffast-math, it breaks ties away from<br>
> zero. That is, in corner cases the result is incorrectly rounded.<br>
><br>
><br>
> Is this intended? This (BGQ with Clang) is the first system that does<br>
> so. (I understand why one would do this given the machine<br>
> instructions available.)<br>
<br>
</div>Yes, this is the intended behavior (and LLVM will currently do this on all PPC systems). It is a function of the (odd) way in which the PPC frin instruction is defined. The upside is that it is much faster than the libc function call. That having been said, I put this optimization in, and I can take it out again ;) [or make it require some other flag]. Is the behavior too different for you?<br>
</blockquote><div><br></div><div>I can live with this optimization, I just want to know where -ffast-math has its boundaries...</div><div><br></div><div>-erik</div><div><br></div><div>-- <br></div></div>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br>
<a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a>
</div></div>