<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Here are suggested words for filling in the missing specification in the unusual arithmetic conversions:<br class=""><br class="">Replace:<br class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">Otherwise, if the corresponding real type of either operand is a standard floating type, the other operand is converted, without change of type domain, to a type whose corresponding real type is that same standard floating type.</blockquote><div class=""><br class=""></div>with:<br class=""> <br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">Otherwise, if the corresponding real type of either operand is long double, the other operand is converted, without change of type domain, to a type whose corresponding real type is long double.</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class="">Otherwise, if the corresponding real type of either operand is double, the other operand is converted, without change of type domain, to a type whose corresponding real type is double.</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class="">Otherwise, if the corresponding real type of either operand is _Float128x or _Decimal128x, the other operand is converted, without change of type domain, to a type whose corresponding real type is _Float128x or _Decimal128x, respectively.</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class="">Otherwise, if the corresponding real type of either operand is _Float64x or _Decimal64x, the other operand is converted, without change of type domain, to a type whose corresponding real type is _Float64x or _Decimal64x, respectively.</blockquote><br class="">I like Joseph’s idea about having the tgmath specification refer to the usual arithmetic conversions. This could be done in Part 2 by replacing:<br class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">… use of a type-generic macro invokes a function whose generic parameters have the corresponding real type determined by the corresponding real types of the arguments as follows:</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""> … bullets</blockquote><br class="">with:<br class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">… use of a type-generic macro invokes a function whose generic parameters have the corresponding real type determined by the types of the arguments for the generic parameters as follows:</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">-- Arguments of integer type are regarded as having type _Decimal64 if any argument has decimal floating type, and as having type double otherwise.</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">-- If the function has exactly one generic parameter, the type determined is the corresponding real type of the argument for the generic parameter.</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">-- If the function has exactly two generic parameters, the type determined is the corresponding real type determined by the usual arithmetic conversions (6.3.1.8) applied to the arguments for the generic parameters.</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">-- If the function has more than two generic parameters, the type determined is the corresponding real type determined by repeatedly applying the ususal arithmetic conversions, first to the first two arguments for generic parameters, then to that result type and the next argument for a generic parameter, and so forth until the usual arithmetic conversions have been applied to the last argument for a generic parameter.</blockquote></blockquote><br class="">I don’t think this would be a substantive change to Part 2.<br class=""><br class="">The change would cover Part 3 too, so no change to the bullets that resolve the type would be needed there. As Joseph notes, the change would be substantive (though believed minor) for Part 3.<br class=""><br class="">Maybe a better approach would be leave Part 2 alone and in Part 3 change the bullets to refer to the usual arithmetic conversions. Otherwise, the change in Part 3 would be dependent on the change in Part 2, which might cause confusion.<div class=""><br class=""></div><div class="">Jim Thomas<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 16, 2016, at 3:41 PM, Joseph Myers <<a href="mailto:joseph@codesourcery.com" class="">joseph@codesourcery.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">C11 specifies that the usual arithmetic conversions on the pair of types <br class="">(long double, double) produces a result of type long double.<br class=""><br class="">Suppose long double and double have the same set of values. TS 18661-3 <br class="">rewrites the rules for usual arithmetic conversions so that the case "if <br class="">both operands are floating types and the sets of values of their <br class="">corresponding real types are equivalent" prefers interchange types to <br class="">standard types to extended types. But this leaves the case of (long <br class="">double, double) unspecified as to which type is chosen, unlike in C11, as <br class="">those are both standard types.<br class=""><br class="">I think this is a defect in TS 18661-3, and it should say that if both are <br class="">standard types with the same set of values then long double is preferred <br class="">to double which is preferred to float, as in C11.<br class=""><br class="">A similar issue could arise if two of the extended types have equivalent <br class="">sets of values. I'm not aware of anything to prohibit that, although it <br class="">seems less likely in practice. I think the natural fix would be to say <br class="">that _Float128x is preferred to _Float64x which is preferred to _Float32x.<br class=""><br class="">I think such an issue would also arise for <tgmath.h> (if _Float64x and <br class="">_Float128x have the same set of values, the choice doesn't seem to be <br class="">specified). It also seems possible for the <tgmath.h> rules for purely <br class="">floating-point arguments to produce a different result from the usual <br class="">arithmetic conversions (consider the case where _Float32x is wider than <br class="">long double, and <tgmath.h> chooses long double), and since rules that are <br class="">the same in most cases but subtly different in obscure cases tend to be <br class="">confusing, I wonder if it might be better to specify much simpler rules <br class="">for <tgmath.h>: take the type resulting from the usual arithmetic <br class="">conversions[*], where integer arguments are replaced by _Decimal64 if <br class="">there are any decimal arguments and double otherwise. (That's different <br class="">from the present rules for e.g. (_Float32x, int), but it's a lot simpler, <br class="">and seems unlikely in practice to choose a type with a different set of <br class="">values from the present choice.)<br class=""><br class="">[*] Meaningful for more than two arguments as long as the usual arithmetic <br class="">conversions are commutative and associative as an operation on pairs of <br class="">types.<br class=""><br class="">-- <br class="">Joseph S. Myers<br class=""><a href="mailto:joseph@codesourcery.com" class="">joseph@codesourcery.com</a><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>