[Cfp-interest 2602] Re: draft CFP response for NB comments and N3071
Jim Thomas
jaswthomas at sbcglobal.net
Sun Jan 8 15:48:56 PST 2023
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/20230108/e77d15e8/attachment.htm>
More information about the Cfp-interest
mailing list