[Cfp-interest] Fwd: (SC22WG14.12737) Observations on N1631

[Jim Thomas]

Begin forwarded message:

> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: (SC22WG14.12737) Observations on N1631
> Date: October 6, 2012 4:30:27 PM PDT
> To: "Joseph S. Myers" <jsm at polyomino.org.uk>
> Cc: sc22wg14 at open-std.org
> 
> 
> On Oct 5, 2012, at 1:30 PM, Joseph S. Myers wrote:
> 
>> On Sun, 30 Sep 2012, Jim Thomas wrote:
>> 
>>>> - Does this recommended practice include recommending that negation, 
>>>>  fabs and copysign raise that exception for signaling NaNs?  (Those 
>>>>  being quiet-computational operations in 754-2008, I'm not sure what 
>>>>  the intent of 754-2008 is regarding what they do with signaling NaNs - 
>>>>  5.5.1 says "signal no exception", unconditionally, but 6.2 refers to 
>>>>  "Every general-computational and quiet-computational operation 
>>>>  involving one or more input NaNs, *none of them signaling* ..." (my 
>>>>  emphasis).)
>>> 
>>> The intention in 754-2008 and the CFP spec is that these operations 
>>> raise no floating-point exceptions, even if the input is a signaling 
>>> NaN. 754-2008 clearly states this in 5.5.1, and doesn't contradict 
>>> itself in 6.2 (although 6.2 could have been more definitive). However, I 
>>> don't see were C11 or the CFP spec says this, except by reference to 
>>> 754. We'll look into it.
>> 
>> A further observation on these three operations:
>> 
>> fabs and copysign are functions.  This means that the argument is 
>> converted, as if by assignment, to the argument type of the function.  So 
>> the wording at the top of page 9 applies, "Whether C assignment (6.5.16) 
>> (and conversion as if by assignment) to the same format is an IEC 60559 
>> convertFormat or copy operation is implementation-defined, even if 
>> <fenv.h> defines the macro FE_SNANS_ALWAYS_SIGNAL (F.2.1).": the signaling 
>> NaN argument might get converted to the same format, so raising the 
>> "invalid" exception and changing it to a quiet NaN, before the being 
>> passed to the function.  (Something similar applies to other functions: 
>> for example, passing an infinity and a signaling NaN to hypot could result 
>> in an "invalid" exception and an infinity rather than quiet NaN return, if 
>> the conversion happens before the function is called.)
>> 
>> All three operations - fabs, copysign and negation - return values that 
>> can't actually be used without assigning, or converting as if by 
>> assignment (e.g. passing to another function).  So you can't actually rely 
>> on doing anything useful with a signaling NaN return value.
>> 
>> This limitation doesn't render the binding *wrong*, but perhaps less 
>> useful than desired.  I suppose that to be able to use those operations 
>> usefully on signaling NaNs, you'd need versions of them defined to store 
>> the result through a pointer, rather than through returning a 
>> floating-point value (and to take arguments either through a pointer, or 
>> as a macro rather than a function).
>> 
>> (No such issue applies to the classification macros, since (a) they are 
>> macros, without the argument-conversion issue, and (b) they return 
>> integers, not floating-point values, so don't have the 
>> return-value-conversion issue.)
>> 
>> (I don't think you can avoid having the wording allowing for convertFormat 
>> operations on function call and return if you want to work with existing 
>> function-call ABIs.  For example, the i386 SysV ABI passes return values 
>> in extended-precision floating-point registers, resulting in conversion 
>> operations if you try to use a binary32 or binary64 signaling NaN return 
>> value.)
> 
> 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. 
> 
> 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.
> 
> -Jim
> 
>> 
>> -- 
>> Joseph S. Myers
>> joseph at codesourcery.com
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20121006/92824037/attachment.html