<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net">jaswthomas@sbcglobal.net</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: (SC22WG14.12737) Observations on N1631</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">October 6, 2012 4:30:27 PM PDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">"Joseph S. Myers" <<a href="mailto:jsm@polyomino.org.uk">jsm@polyomino.org.uk</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Cc: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><a href="mailto:sc22wg14@open-std.org">sc22wg14@open-std.org</a><br></span></div><br><div><br>On Oct 5, 2012, at 1:30 PM, Joseph S. Myers wrote:<br><br><blockquote type="cite">On Sun, 30 Sep 2012, Jim Thomas wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">- Does this recommended practice include recommending that negation, <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> fabs and copysign raise that exception for signaling NaNs? (Those <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> being quiet-computational operations in 754-2008, I'm not sure what <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> the intent of 754-2008 is regarding what they do with signaling NaNs - <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> 5.5.1 says "signal no exception", unconditionally, but 6.2 refers to <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> "Every general-computational and quiet-computational operation <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> involving one or more input NaNs, *none of them signaling* ..." (my <br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> emphasis).)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The intention in 754-2008 and the CFP spec is that these operations <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">raise no floating-point exceptions, even if the input is a signaling <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">NaN. 754-2008 clearly states this in 5.5.1, and doesn't contradict <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">itself in 6.2 (although 6.2 could have been more definitive). However, I <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">don't see were C11 or the CFP spec says this, except by reference to <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">754. We'll look into it.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">A further observation on these three operations:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">fabs and copysign are functions. This means that the argument is <br></blockquote><blockquote type="cite">converted, as if by assignment, to the argument type of the function. So <br></blockquote><blockquote type="cite">the wording at the top of page 9 applies, "Whether C assignment (6.5.16) <br></blockquote><blockquote type="cite">(and conversion as if by assignment) to the same format is an IEC 60559 <br></blockquote><blockquote type="cite">convertFormat or copy operation is implementation-defined, even if <br></blockquote><blockquote type="cite"><fenv.h> defines the macro FE_SNANS_ALWAYS_SIGNAL (F.2.1).": the signaling <br></blockquote><blockquote type="cite">NaN argument might get converted to the same format, so raising the <br></blockquote><blockquote type="cite">"invalid" exception and changing it to a quiet NaN, before the being <br></blockquote><blockquote type="cite">passed to the function. (Something similar applies to other functions: <br></blockquote><blockquote type="cite">for example, passing an infinity and a signaling NaN to hypot could result <br></blockquote><blockquote type="cite">in an "invalid" exception and an infinity rather than quiet NaN return, if <br></blockquote><blockquote type="cite">the conversion happens before the function is called.)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">All three operations - fabs, copysign and negation - return values that <br></blockquote><blockquote type="cite">can't actually be used without assigning, or converting as if by <br></blockquote><blockquote type="cite">assignment (e.g. passing to another function). So you can't actually rely <br></blockquote><blockquote type="cite">on doing anything useful with a signaling NaN return value.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This limitation doesn't render the binding *wrong*, but perhaps less <br></blockquote><blockquote type="cite">useful than desired. I suppose that to be able to use those operations <br></blockquote><blockquote type="cite">usefully on signaling NaNs, you'd need versions of them defined to store <br></blockquote><blockquote type="cite">the result through a pointer, rather than through returning a <br></blockquote><blockquote type="cite">floating-point value (and to take arguments either through a pointer, or <br></blockquote><blockquote type="cite">as a macro rather than a function).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(No such issue applies to the classification macros, since (a) they are <br></blockquote><blockquote type="cite">macros, without the argument-conversion issue, and (b) they return <br></blockquote><blockquote type="cite">integers, not floating-point values, so don't have the <br></blockquote><blockquote type="cite">return-value-conversion issue.)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(I don't think you can avoid having the wording allowing for convertFormat <br></blockquote><blockquote type="cite">operations on function call and return if you want to work with existing <br></blockquote><blockquote type="cite">function-call ABIs. For example, the i386 SysV ABI passes return values <br></blockquote><blockquote type="cite">in extended-precision floating-point registers, resulting in conversion <br></blockquote><blockquote type="cite">operations if you try to use a binary32 or binary64 signaling NaN return <br></blockquote><blockquote type="cite">value.)<br></blockquote><br>The optional support we're proposing for signaling NaNs just amounts to the basic behavior that they do raise "invalid" when they're an operand for a operation specified to do so (per IEC 60559). This in itself doesn't allow one to do much with signaling NaNs beyond detect data initialized with them. However, our basic support might be helpful to an implementation in providing some feature that uses signaling NaNs in conjunction with extensions like special traps and handlers. Depending on the application, it might be ok for the "invalid" exception to occur on implicit conversions. If not, the application might be limited to implementations that can provide same-format conversions as copy operations. <br><br>Admittedly, discussion here is somewhat vague. Our support for signaling NaNs isn't in itself a complete solution, and there is little prior art for applications of signaling NaNs. The IEEE 754 revision committee seriously considered removing them from their standard. Although there have been promising rough ideas for applications, the committee was not able to find any significant real examples. On the other hand, the committee was reluctant to conclude there truly were no applications that relied on basic signaling NaN support which is now in most hardware; such applications would be undercut if support was omitted in new hardware because it had been removed from the floating point standard. So signaling NaNs remained in IEC 60559. Our intention is to provide the support required by IEC 60559, as an option that minimally impacts the specification and implementations that do not provide the option.<br><br>-Jim<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">-- <br></blockquote><blockquote type="cite">Joseph S. Myers<br></blockquote><blockquote type="cite"><a href="mailto:joseph@codesourcery.com">joseph@codesourcery.com</a><br></blockquote><br></div></blockquote></div><br></body></html>