<br><br><div class="gmail_quote">On Fri, Nov 2, 2012 at 10:02 AM, Krzysztof Parzyszek <span dir="ltr"><<a href="mailto:kparzysz@codeaurora.org" target="_blank">kparzysz@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 11/2/2012 11:53 AM, Michael Ilseman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
I think Dan was making two points with his example. Dan, correct me if I misrepresent your example, but image a situation where a target has two instructions to choose between in order to perform the operation. The first is IEEE compliant, but the second isn't compliant in how it operates over NaNs (quiet or otherwise). For whatever reason, the second is preferred when we know inputs are not NaN.<br>

<br>
The first point is that I didn't specify if the N bit would allow the target to choose the non-compliant operation.<br>
<br>
The second point is that my specifying "undefined value" isn't enough. What if the non-compliant instruction's behavior on NaN was to trap. It's not just an invalid/random bit pattern, but actual behavioral differences.<br>
</blockquote></div></blockquote><div><br></div><div>That's right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

</blockquote>
<br></div>
I see.  The situation is that the user tells the compiler to "ignore" NaNs, and yet the program does produce a NaN.  The compiler generates the trapping instruction (expecting that the trap won't happen), but because of the NaN, the trap does occur.<br>

<br>
My definition of the N flag would be that it instructs the compiler that the computations do not involve or produce NaNs.  In other words, when, as a programmer, I use the N flag, I'm telling the compiler that I don't expect NaNs to ever appear in the computations.  If a NaN did appear and produced a trap, it would be just as unexpected as seeing a NaN in the output without a trap.<br>
</blockquote><div><br></div><div>Just so you know, what you're describing sounds like Undefined Behavior.</div><div><br></div><div>I don't currently have a suggestion for what is best choice is, or of how important it is.</div>
<div><br></div><div>Dan</div><div><br></div></div>