[Cfp-interest] Fwd: (SC22WG14.14928) Floating-point DR#13 and integer arguments to type-generic macros

[Jim Thomas]

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.

We can address this by changing row 3 of the table in N2213 from

fM	|	_FloatMx if supported, else _FloatN for minimum N > M

to

fM	|	_FloatN for minimum N > M if supported, else _FloatMx

and similarly for row 5.

Also, change the examples

f32add(f32, f32)	f32addf32x(f32, f32)
…

f64div(f32x, f32x)	f64divf64x(f32x, f32x) if _Float64x
				is supported, else f64divf128


to

f32add(f32, f32)	f32addf64(f32, f32)
…

f64div(f32x, f32x)	f64divf128


- Jim Thomas


> Begin forwarded message:
> 
> From: Joseph Myers <joseph at codesourcery.com>
> Subject: (SC22WG14.14928) Floating-point DR#13 and integer arguments to type-generic macros
> Date: March 19, 2018 at 10:43:37 AM PDT
> To: <sc22wg14 at open-std.org>
> 
> Regarding the latest version in N2213:
> 
> This version does seem to make the chosen functions unambiguous, but it 
> also leaves the chosen functions in some decimal floating-point cases 
> different from what they are in TS 18661-2.
> 
> Consider the d64add(d32, d32) example in TS 18661-2, which is specified 
> there as resulting in a call to d64addd128.  Under the new proposal, 
> because there is no d64addd32 function, it would call d64addd64x.  This 
> difference isn't observable to the user, but at very least the example 
> would need updating, to reflect that in the case where 
> __STDC_IEC_60559_TYPES__ is defined d64addd64x is called (whereas if 
> __STDC_IEC_60559_TYPES__ isn't defined, neither _Decimal64x nor _Decimal96 
> is supported and so the new wording would result in the same function 
> choice as in TS 18661-2).
> 
> If the arguments to d64add had a 128-bit integer type and _Decimal64x had 
> less precision than _Decimal128, the difference in results would be 
> user-visible.  (Note, however, that I don't know if there are any existing 
> implementations of the narrowing functions for decimal floating point, or 
> of the associated type-generic macros, or of _Decimal64x, or of 
> _Decimal96.)
> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com
> 
> On Mon, 12 Feb 2018, Joseph Myers wrote:
> 
>> I believe these comments all still apply to the version of the DR 
>> resolution in N2202: it still determines a type, but says nothing about 
>> what function is determined from that type (needed to cover dadd(f, f) 
>> which needs to call daddl to stay compatible with TS 18661-1, for example 
>> - the type determined is float, but what function is determined from it?).
>> 
>> -- 
>> Joseph S. Myers
>> joseph at codesourcery.com
>> 
>> On Thu, 23 Nov 2017, Joseph Myers wrote:
>> 
>>> Looking at the latest proposed DR resolution 
>>> <http://wiki.edg.com/pub/CFP/WebHome/tgmath_for_narrowing_functions-20171117.pdf>:
>>> 
>>> This resolution changes text that partially determines a function called 
>>> by type-generic macros such as dadd, to text that determines a type.  Does 
>>> it then result in a call to a function whose parameters have that type?  I 
>>> don't see anything saying so, but it's possible I've missed some text in 
>>> the complicated sequence of (C11 amended by 18661-1 amended by 18661-2 
>>> amended by 18661-3 amended by DR#9 amended by DR#13 as modified by this 
>>> proposed change to the resolution of DR#13).
>>> 
>>> In any case, there needs to be *something* about choosing a function whose 
>>> arguments have a wider type than the one determined from the types of the 
>>> arguments (subject to whatever's needed to keep things well-defined in the 
>>> case of integer arguments, if desired), because of the dadd(f, f) case, 
>>> which is clearly specified in TS 18661-1 to call the function daddl, and 
>>> is included as an example there - as there isn't any dadd function with 
>>> float or double arguments.  A correction to TS 18661-3 should not have the 
>>> effect of invalidating something that was valid with TS 18661-1.
>>> 
>>> -- 
>>> Joseph S. Myers
>>> joseph at codesourcery.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20180405/e11f29eb/attachment.html