<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="">It’s troublesome that our N2213 tgmath spec for part 3 determines different functions than part 1, particularly if the difference is conceivably user visible, even if the difference is not user visible on current implementations.<div class=""><br class=""></div><div class="">We can address this by changing row 3 of the table in N2213 from</div><div class=""><br class=""></div><div class="">fM<span class="Apple-tab-span" style="white-space:pre"> </span>|<span class="Apple-tab-span" style="white-space:pre"> </span>_FloatMx if supported, else _FloatN for minimum N > M</div><div class=""><br class=""></div><div class="">to</div><div class=""><br class=""></div><div class="">fM<span class="Apple-tab-span" style="white-space:pre"> </span>|<span class="Apple-tab-span" style="white-space:pre"> </span>_FloatN for minimum N > M if supported, else _FloatMx</div><div class=""><br class=""></div><div class="">and similarly for row 5.</div><div class=""><br class=""></div><div class="">Also, change the examples</div><div class=""><br class=""></div><div class="">f32add(f32, f32)<span class="Apple-tab-span" style="white-space:pre"> </span>f32addf32x(f32, f32)</div><div class="">…</div><div class=""><br class=""></div><div class="">f64div(f32x, f32x)<span class="Apple-tab-span" style="white-space:pre"> </span>f64divf64x(f32x, f32x) if _Float64x</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>is supported, else f64divf128</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">to</div><div class=""><br class=""></div><div class=""><div class="">f32add(f32, f32)<span class="Apple-tab-span" style="white-space: pre;"> </span>f32addf64(f32, f32)</div><div class="">…</div><div class=""><br class=""></div><div class="">f64div(f32x, f32x)<span class="Apple-tab-span" style="white-space: pre;"> </span>f64divf128</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">- Jim Thomas</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Begin forwarded message:</div><br class="Apple-interchange-newline"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">From: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">Joseph Myers <<a href="mailto:joseph@codesourcery.com" class="">joseph@codesourcery.com</a>><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Subject: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><b class="">(SC22WG14.14928) Floating-point DR#13 and integer arguments to type-generic macros</b><br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">Date: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class="">March 19, 2018 at 10:43:37 AM PDT<br class=""></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=""><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; color:rgba(0, 0, 0, 1.0);" class=""><b class="">To: </b></span><span style="font-family: -webkit-system-font, Helvetica Neue, Helvetica, sans-serif;" class=""><<a href="mailto:sc22wg14@open-std.org" class="">sc22wg14@open-std.org</a>><br class=""></span></div><br class=""><div class=""><div class="">Regarding the latest version in N2213:<br class=""><br class="">This version does seem to make the chosen functions unambiguous, but it <br class="">also leaves the chosen functions in some decimal floating-point cases <br class="">different from what they are in TS 18661-2.<br class=""><br class="">Consider the d64add(d32, d32) example in TS 18661-2, which is specified <br class="">there as resulting in a call to d64addd128. Under the new proposal, <br class="">because there is no d64addd32 function, it would call d64addd64x. This <br class="">difference isn't observable to the user, but at very least the example <br class="">would need updating, to reflect that in the case where <br class="">__STDC_IEC_60559_TYPES__ is defined d64addd64x is called (whereas if <br class="">__STDC_IEC_60559_TYPES__ isn't defined, neither _Decimal64x nor _Decimal96 <br class="">is supported and so the new wording would result in the same function <br class="">choice as in TS 18661-2).<br class=""><br class="">If the arguments to d64add had a 128-bit integer type and _Decimal64x had <br class="">less precision than _Decimal128, the difference in results would be <br class="">user-visible. (Note, however, that I don't know if there are any existing <br class="">implementations of the narrowing functions for decimal floating point, or <br class="">of the associated type-generic macros, or of _Decimal64x, or of <br class="">_Decimal96.)<br class=""><br class="">-- <br class="">Joseph S. Myers<br class=""><a href="mailto:joseph@codesourcery.com" class="">joseph@codesourcery.com</a><br class=""><br class="">On Mon, 12 Feb 2018, Joseph Myers wrote:<br class=""><br class=""><blockquote type="cite" class="">I believe these comments all still apply to the version of the DR <br class="">resolution in N2202: it still determines a type, but says nothing about <br class="">what function is determined from that type (needed to cover dadd(f, f) <br class="">which needs to call daddl to stay compatible with TS 18661-1, for example <br class="">- the type determined is float, but what function is determined from it?).<br class=""><br class="">-- <br class="">Joseph S. Myers<br class="">joseph@codesourcery.com<br class=""><br class="">On Thu, 23 Nov 2017, Joseph Myers wrote:<br class=""><br class=""><blockquote type="cite" class="">Looking at the latest proposed DR resolution <br class=""><http://wiki.edg.com/pub/CFP/WebHome/tgmath_for_narrowing_functions-20171117.pdf>:<br class=""><br class="">This resolution changes text that partially determines a function called <br class="">by type-generic macros such as dadd, to text that determines a type. Does <br class="">it then result in a call to a function whose parameters have that type? I <br class="">don't see anything saying so, but it's possible I've missed some text in <br class="">the complicated sequence of (C11 amended by 18661-1 amended by 18661-2 <br class="">amended by 18661-3 amended by DR#9 amended by DR#13 as modified by this <br class="">proposed change to the resolution of DR#13).<br class=""><br class="">In any case, there needs to be *something* about choosing a function whose <br class="">arguments have a wider type than the one determined from the types of the <br class="">arguments (subject to whatever's needed to keep things well-defined in the <br class="">case of integer arguments, if desired), because of the dadd(f, f) case, <br class="">which is clearly specified in TS 18661-1 to call the function daddl, and <br class="">is included as an example there - as there isn't any dadd function with <br class="">float or double arguments. A correction to TS 18661-3 should not have the <br class="">effect of invalidating something that was valid with TS 18661-1.<br class=""><br class="">-- <br class="">Joseph S. Myers<br class="">joseph@codesourcery.com<br class=""></blockquote></blockquote></div></div></blockquote></div><br class=""></div></body></html>