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