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

[Jim Thomas]

> On Jan 6, 2023, at 12:50 PM, Joseph Myers <joseph at codesourcery.com> wrote:
> 
> On Fri, 6 Jan 2023, Jim Thomas wrote:
> 
>> Here’s a draft for the CFP responses for NB comments on the C23 CD. The 
>> responses are based on our review at the two CFP teleconferences this 
>> week (January 4 and 5). Also, I have included a response with a proposal 
>> for the issues raised in N3071.
>> 
>> Please review the paper and send any corrections or additions ASAP. Give 
>> special attention to the section “About N3071”, much of which was 
>> written after the CFP review meetings. I plan to update the draft, 
>> incorporating your input, and submit it to WG14 on Monday, January 9.
>> 
>> https://wiki.edg.com/pub/CFP/WebHome/CFP_review_of_NB_comments-20230106.pdf
> 
> 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?

> So I'd be fine with applying the GB-164 change only for errno 
> and not for exceptions.)

That might be a reasonable compromise if the benefit of the change to errno isn't worth the cost.
> 
> 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”.

and 

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”.
> 
> N3071: "shall have the same type as the initializer" isn't quite right; 
> the constexpr object is always (implicitly) const, but the initializer 
> isn't because it's an rvalue, so it should rather be that the unqualified 
> versions of the types are compatible (compatible is the usual notion, not 
> same).  And I'd tend to expect a real sNaN to be suitable for initializing 
> an object of the corresponding complex type (but not a different complex 
> type), since no conversion is then applied to the real part - although I 
> don't think any existing normative specification requires that to produce 
> (sNaN, +0) as the result.

Maybe

“ … If the initializer has real type and a signaling NaN value, the unqualified versions of the type of the initializer and the corresponding real type of the object declared shall be compatible.”

The above leaves behavior of signaling NaNs unspecified in generally valid cases involving complex and imaginary types. The behavior of signaling NaNs for complex and imaginary types is generally unspecified or sketchily specified.

- Jim Thomas

> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230106/206ff1d2/attachment.htm>