<div dir="ltr"><div dir="ltr">On Mon, Sep 13, 2021 at 10:09 AM Krzysztof Parzyszek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-4745683397371413458WordSection1"><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b>From:</b> Serge Pavlov <<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>> <br><span style="text-align:center">`isnan` does not begin with an underscore, so it is not a reserved identifier. Why is its redefinition an UB?</span></blockquote></div></div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-4745683397371413458WordSection1">
<p class="MsoNormal">The standard says so, but I can’t find the corresponding passage in the draft...<u></u><u></u></p>
<p class="MsoNormal"><u></u></p></div></div></blockquote><div><br></div><div>I don't know about C, but in C++ redefining any library name as a macro is forbidden by</div><div><a href="https://eel.is/c++draft/reserved.names#macro.names-1">https://eel.is/c++draft/reserved.names#macro.names-1</a></div><div><br></div><div>Btw, I don't think this thread has paid enough attention to Richard Smith's suggestion: that in fast-math mode, the implementation should</div><div>- treat all quiet NaNs as if they are signaling NaNs</div><div>- treat all "signals" as if they <strike>are UB</strike> <u>produce an unspecified value</u></div><div>So, any floating-point operations that IEEE754 guarantees will work silently even on signaling NaNs, must continue to work on any kind of NaN in fast-math mode. But any operation that is allowed to signal, is therefore allowed to give wrong results if you feed it any kind of NaN in fast-math mode. In this model, we don't talk about specific mathematical identities like "x+0 == x". Instead, we say "If !isnan(x), then computationally x+0 == x; and if isnan(x), then x+0 is allowed to signal and therefore in fast-math mode we can make its result come out to any value we like. Therefore, if the optimizer sometimes wants to pretend that QNAN + 0 == QNAN, that's perfectly acceptable."</div><div><br></div><div>Notice that you cannot make "signaling" into actual UB; you must make it <u>produce an unspecified value</u>. If you make it UB, then the compiler will happily optimize</div><div><br></div><div>    {</div><div>        if (!isnan(someGlobal)) puts("it's not nan");  // #1</div><div>        double x = someGlobal;</div><div>        x += 1;  // This is a signaling operation<br></div><div>    }</div><div><br></div><div>into</div><div><br></div><div>    {</div><div>        puts("it's not nan");  // because if it were NaN on line #1, then either we'd hit that signaling operation, or we'd have a data race</div><div>    }</div><div><br></div><div>But if you just make "signaling" operations produce unspecified values when given NaN, then I think everything works fine and you end up with behavior that's pretty darn close to what Serge is advocating for with his "New" behavior.</div><div><br></div><div>my $.02,</div><div>–Arthur</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>