<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So what is the verdict here? In my original question the host has a _<i>bug</i>_ in the implementation of fetestexcept() . Why it should affect the correctness of the code I produce?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Sergei<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas;color:#1F497D'>---<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation</span><span style='font-size:10.5pt;font-family:Consolas;color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu] <b>On Behalf Of </b>Chandler Carruth<br><b>Sent:</b> Saturday, April 27, 2013 6:18 PM<br><b>To:</b> Nick Lewycky<br><b>Cc:</b> LLVM Developers Mailing List<br><b>Subject:</b> Re: [LLVMdev] ConstantFoldBinaryFP and cross compilation<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Sat, Apr 27, 2013 at 7:26 PM, Nick Lewycky <<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>> wrote:<o:p></o:p></p><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>On 04/26/2013 04:20 PM, Owen Anderson wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal><br>On Apr 26, 2013, at 3:07 PM, Sergei Larin <<a href="mailto:slarin@codeaurora.org" target="_blank">slarin@codeaurora.org</a><o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><mailto:<a href="mailto:slarin@codeaurora.org" target="_blank">slarin@codeaurora.org</a>>> wrote:<o:p></o:p></p><div><p class=MsoNormal>Dan,<br>Thank you for the quick and throughout reply. First paragraph pretty<br>much sums it up. Unless there is more will to guaranty (or provide<br>under flag) stricter version of IEEE adherence, I doubt much can be done.<o:p></o:p></p></div><p class=MsoNormal>So all of you with picky customers out thereJIs there anyone else that<o:p></o:p></p><div><p class=MsoNormal><br>would be concerned about this problem in any of it potential forms?<o:p></o:p></p></div><div><p class=MsoNormal><br>I have the opposite problem. I have customers who call libm functions<br>with constants (or their LLVM intrinsic equivalents) are get very angry<br>if they don't get constant folded, and they're not picky at all about<br>the precision.<o:p></o:p></p></div></blockquote><p class=MsoNormal><br>I just want LLVM to behave the same on whatever platform it's run on. People already accept that depending on iteration order is a bug, but it's been harder to get people to accept that llvm needs bit-exact floating point constant folding, especially given the implementation difficulty.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'll give a huge +1 to this.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think that long-term LLVM should, out of the box, support strictly correct (according to IEEE) floating point folding outside of fast-math, and should provide aggressive as hell folding inside of fast-math.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>As Owen points out rightly, it would be important to provide flags to enable just the amount of folding that users have today and expect to keep, preferably as some rational subset of fast math.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>However, I don't think either aggressive folding in fast-math or conservative behavior by default is nearly as important as what Nick pointed out: we should not under any circumstances expose the output of the optimizer to the whims of the host's FP. Even if we can write code to get deterministic results out of the host's FP unit (maybe, but hard and a huge maintenance burden), and even if the host's FP unit actually gives us deterministic results (questionable on some older chips), I most certainly don't want to assume that the host *compiler* will actually handle LLVM's host FP code correctly, especially given the current quality of LLVM's own optimizer for such code! =/ We should insulate ourselves from such concerns completely.<o:p></o:p></p></div></div></div></div></div></div></body></html>