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

[Jim Thomas]

One approach would be to append a bullets in the new text in N2202, saying something like

—	If  no function with the given prefix has the parameter type determined above, the type is determined from the prefix as follows:

prefix	type
------	----------------------------------------------------------------------------------------
f		double
d		long double
fM		_FloatMx if supported, else _FloatN for minimal N > M
fMx		_FloatNx for minimal N > M if supported, else _FloatN for minimal N > M
dM		_DecimalMx if supported, else _DecimalN for minimal N > M
dMx		_DecimalNx for minimal N > M if supported, else _DecimalN for minimal N > M

and append to the table of examples:

f32add(f32, f32)	f32addf32x(f32, f32) 
f32xsqrt(f32)		f32xsqrtf64x(f32) if _Float64x is supported, else f32xsqrtf64
f64div(f32x, f32x)	f64divf64x(f32x, f32x) if _Float64x is supported, else f64divf128 

This needs more thought. We’ll discuss it at the Feb 20 CFP teleconference.

- Jim Thomas

> On Feb 13, 2018, at 10:42 AM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> We’ll add this issue to the agenda for the Feb 20 teleconference.
> 
> - Jim Thomas
> 
>> Begin forwarded message:
>> 
>> From: Joseph Myers <joseph at codesourcery.com <mailto:joseph at codesourcery.com>>
>> Subject: (SC22WG14.14921) Floating-point DR#13 and integer arguments to type-generic macros
>> Date: February 12, 2018 at 9:46:11 AM PST
>> To: <sc22wg14 at open-std.org <mailto:sc22wg14 at open-std.org>>
>> 
>> 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 <mailto: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/20180218/c6b2a087/attachment.html