[Cfp-interest 2603] Re: draft CFP response for NB comments and N3071

[Jim Thomas]

Here’s our document I submitted to WG14.

https://wiki.edg.com/pub/CFP/WebHome/n3081.pdf

- Jim Thomas

> On Jan 8, 2023, at 3:48 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> If I receive any more additions or correction by noon PST tomorrow (Monday, January 9), I will try to incorporate them into the document I submit to WG14 (before the 2-week deadline).
> 
> - Jim Thomas
> 
> 
>> On Jan 7, 2023, at 9:51 AM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
>> 
>> Here’s an update to the draft, intended to address the issues raised by Joseph. Added or changed text is highlighted.
>> 
>> https://wiki.edg.com/pub/CFP/WebHome/CFP_review_of_NB_comments-20230107.pdf
>> 
>> - Jim Thomas
>> 
>>> On Jan 6, 2023, at 6:03 PM, Joseph Myers <joseph at codesourcery.com> wrote:
>>> 
>>> On Fri, 6 Jan 2023, Jim Thomas wrote:
>>> 
>>>>> GB-164: I'll disagree with the disagreement here (I assume this will end 
>>>>> up needing to be discussed in the WG14 meeting), since the semantic change 
>>>>> in C2x (which I don't think was ever explicitly discussed as an intended 
>>>>> semantic change in a paper) would make errno-setting implementations of 
>>>>> various functions much more complicated and less efficient - detecting 
>>>>> overflow after the fact (in a way that's valid for previous versions of C) 
>>>>> by checking for an infinite results from finite arguments is very 
>>>>> straightforward, determining based on the arguments whether pow, fdim, 
>>>>> hypot or fma (for example) would overflow / whether a result of the 
>>>>> largest finite value is an overflow is much more complicated and 
>>>>> inefficient (and saving and restoring exceptions so as to test, for the 
>>>>> purposes of errno setting, whether the overflow exception was raised, is 
>>>>> also inefficient; such explicit manipulations of floating-point state are 
>>>>> liable to empty the processor pipeline).  (This concern is specifically 
>>>>> about errno setting rather than exceptions; ensuring the overflow 
>>>>> exception is raised for overflow to a finite number isn't a problem in the 
>>>>> same way.  
>>>> 
>>>> Could you determine overflow errno setting from the overflow 
>>>> floating-point exception?
>>> 
>>> See above.  If a function has to save and restore floating-point state 
>>> explicitly, it's liable to be bad for pipelined execution (so efficiency).  
>>> (And the "save and restore" part is necessary, since the overflow flag 
>>> might already be raised on entry to the function.)
>>> 
>>>>> GB-279: The wording of some of the changes isn't quite right (constexpr 
>>>>> isn't a storage *duration*, so wording shouldn't refer to it as such in 
>>>>> F.8.4 or F.8.5).
>>>> 
>>>> Rewordings might be:
>>>> 
>>>> In F.8.4 #1 change “for an object that has static or thread storage 
>>>> duration” to “for an object declared with storage-class specifier 
>>>> constexpr, static, or thread_local”.
>>> 
>>> That's not correct.  An object with static storage duration might have no 
>>> storage-class specifier, or only the extern specifier, if at file scope.
>>> 
>>>> In F.8.5 #1 change “of objects that have static or thread storage 
>>>> duration” to “of objects declared with storage-class specifier 
>>>> constexpr, static, or thread_local”.
>>> 
>>> Likewise.
>>> 
>>> -- 
>>> Joseph S. Myers
>>> joseph at codesourcery.com
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230109/7d0fa660/attachment.htm>