[Cfp-interest 1782] Re: (SC22WG14.18328) Comments on N2561 (TS 18661-3 as Annex update)

[Jim Thomas]

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.

https://wiki.edg.com/pub/CFP/WebHome/cfp3-annex-20200925.pdf <https://wiki.edg.com/pub/CFP/WebHome/cfp3-annex-20200925.pdf>

- Jim Thomas

> On Sep 14, 2020, at 4:18 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> Thanks, Joseph.
> 
> CFP will consider both these issues and, at its 23 September meeting, decide what changes to make to its annex proposal.
> 
> 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.
> 
> - Jim Thomas
> 
> 
>> On Sep 10, 2020, at 4:30 PM, Joseph Myers <joseph at codesourcery.com> wrote:
>> 
>> Some comments on N2561 (TS 18661-3 as Annex update - note that 
>> http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm has the 
>> descriptions for N2558 and N2561 swapped), where it deviates from the 
>> original TS and subsequent CR resolutions:
>> 
>> * This version introduces changes to default argument promotions for 
>> _Float16, _Float32 and _Float64.  This is a bad idea.  To quote again the 
>> response to DR#206: "real float promotion to double is in Standard C 
>> purely for compatibility with K&R. Since complex is new, that 
>> compatibility is not an issue, and having it behave like real float would 
>> introduce undesired overhead".  Exactly the same reasoning as for _Complex 
>> float applies for these new types: they didn't exist in K&R C, so there is 
>> no need for promotion when passed in variable arguments, and it's more 
>> efficient not to promote them (as well as allowing for the possibility of 
>> a signaling NaN being passed as-is by a copy operation, which cannot 
>> happen when promoted).
>> 
>> * This version has further changes to the rules for choosing a function in 
>> <tgmath.h> for one of the narrowing macros, beyond what appears in the 
>> final version of the response to FPE CR#13, and those changes have 
>> counterintuitive consequences.
>> 
>> My understanding is that the changes to allow standard types to be passed 
>> to a type-generic macro whose name indicates a return type of _FloatN or 
>> _FloatNx, and to allow binary types to be passed when the return type is 
>> float or double, is to avoid problems when arguments are of types such as 
>> _Float32_t, and that's fine.  However, the new rules gives can result in a 
>> function being chosen with a different argument type from the function 
>> arguments, even if there is a function that matches exactly, that the 
>> seems counterintuitive.
>> 
>> For example, say the arguments to f64add are of type _Float64x (or one is 
>> _Float64x and one is of integer type, to get a case when the choice of 
>> function can actually affect the return value), and all _Float64x values 
>> can also be represented as _Float128.  The rules in N2561 would result in 
>> f64addf128 being called.  The rules from CR#13 would result in f64addf64x, 
>> a function with exactly matching argument type, being called, which seems 
>> more intuitive.
>> 
>> Adding a rule that if a corresponding function exists with exactly the 
>> type determined from the macro arguments, then that function is called, 
>> before looking for a big-enough type from the given lists, would avoid 
>> that unintuitive result (and also make the example f32add(f64x, f64) given 
>> as yielding a call to f32addf64x valid again, with the current wording it 
>> looks incorrect to me if _Float128 is supported and represents all the 
>> values of _Float64x).
>> 
>> -- 
>> Joseph S. Myers
>> joseph at codesourcery.com
> 

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