<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Here is a link to an N2561 update which is awaiting an N-number. Changes are in response to Joseph Myers’s comments below. The link is into the CFP wiki. Contact me if you need login information.<div class=""><br class=""></div><div class=""><a href="https://wiki.edg.com/pub/CFP/WebHome/cfp3-annex-20200925.pdf" class="">https://wiki.edg.com/pub/CFP/WebHome/cfp3-annex-20200925.pdf</a></div><div class=""><br class=""></div><div class="">- Jim Thomas<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 14, 2020, at 4:18 PM, Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net" class="">jaswthomas@sbcglobal.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Thanks, Joseph.<br class=""><br class="">CFP will consider both these issues and, at its 23 September meeting, decide what changes to make to its annex proposal.<br class=""><br class="">I’ll provide a more detailed response about this to CFP and Joseph. Let me know if you’re not on the CFP list and would like to be included.<br class=""><br class="">- Jim Thomas<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Sep 10, 2020, at 4:30 PM, Joseph Myers <<a href="mailto:joseph@codesourcery.com" class="">joseph@codesourcery.com</a>> wrote:<br class=""><br class="">Some comments on N2561 (TS 18661-3 as Annex update - note that <br class=""><a href="http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm" class="">http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm</a> has the <br class="">descriptions for N2558 and N2561 swapped), where it deviates from the <br class="">original TS and subsequent CR resolutions:<br class=""><br class="">* This version introduces changes to default argument promotions for <br class="">_Float16, _Float32 and _Float64. This is a bad idea. To quote again the <br class="">response to DR#206: "real float promotion to double is in Standard C <br class="">purely for compatibility with K&R. Since complex is new, that <br class="">compatibility is not an issue, and having it behave like real float would <br class="">introduce undesired overhead". Exactly the same reasoning as for _Complex <br class="">float applies for these new types: they didn't exist in K&R C, so there is <br class="">no need for promotion when passed in variable arguments, and it's more <br class="">efficient not to promote them (as well as allowing for the possibility of <br class="">a signaling NaN being passed as-is by a copy operation, which cannot <br class="">happen when promoted).<br class=""><br class="">* This version has further changes to the rules for choosing a function in <br class=""><tgmath.h> for one of the narrowing macros, beyond what appears in the <br class="">final version of the response to FPE CR#13, and those changes have <br class="">counterintuitive consequences.<br class=""><br class="">My understanding is that the changes to allow standard types to be passed <br class="">to a type-generic macro whose name indicates a return type of _FloatN or <br class="">_FloatNx, and to allow binary types to be passed when the return type is <br class="">float or double, is to avoid problems when arguments are of types such as <br class="">_Float32_t, and that's fine. However, the new rules gives can result in a <br class="">function being chosen with a different argument type from the function <br class="">arguments, even if there is a function that matches exactly, that the <br class="">seems counterintuitive.<br class=""><br class="">For example, say the arguments to f64add are of type _Float64x (or one is <br class="">_Float64x and one is of integer type, to get a case when the choice of <br class="">function can actually affect the return value), and all _Float64x values <br class="">can also be represented as _Float128. The rules in N2561 would result in <br class="">f64addf128 being called. The rules from CR#13 would result in f64addf64x, <br class="">a function with exactly matching argument type, being called, which seems <br class="">more intuitive.<br class=""><br class="">Adding a rule that if a corresponding function exists with exactly the <br class="">type determined from the macro arguments, then that function is called, <br class="">before looking for a big-enough type from the given lists, would avoid <br class="">that unintuitive result (and also make the example f32add(f64x, f64) given <br class="">as yielding a call to f32addf64x valid again, with the current wording it <br class="">looks incorrect to me if _Float128 is supported and represents all the <br class="">values of _Float64x).<br class=""><br class="">-- <br class="">Joseph S. Myers<br class=""><a href="mailto:joseph@codesourcery.com" class="">joseph@codesourcery.com</a><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></body></html>