[Cfp-interest 2136] Fwd: [SC22WG14.20399] tgmath.h narrowing macros with integer arguments

[Jim Thomas]

Joseph found a case that is not properly covered by the tgmath rules for functions that round to narrower type in the Part 3 annex (X.13 in N2601), namely the case where all arguments are of integer type and the macro prefix is dN for some N.

The problem exits because the first step of the type determination rules applies the usual arithmetic conversions which handle integer-type arguments based solely on argument types. This doesn’t work for functions that round to narrower type because the prefix might need to be considered too, as in the case of d32sqrt(n) which Joseph mentions below. (I had checked the rules against a matrix of possibilities with all possible prefixes and all possible floating types, but had assumed integer types were covered by the application of the usual arithmetic conversions.)

Here’s a way of addressing the problem ...

Change the first bullet in X.13 #5:

 — First apply the rules (for determining the corresponding real type of the generic parameters) in 7.25 for macros that do not round result to narrower type, using the usual arithmetic conversion rules in X.4.2, to obtain a preliminary type P for the generic parameters.

to:

 — First, obtain a preliminary type P for the generic parameters: if all arguments are of integer type, then P is double if the macro prefix is  f, d, or dN for some N and P is _Decimal64 if the macro prefix is dN for some N; otherwise (if some argument is not of integer type), apply the rules (for determining the corresponding real type of the generic parameters) in 7.25 for macros that do not round result to narrower type, using the usual arithmetic conversion rules in X.4.2, to obtain P.

This issue will be added to the agenda for the CFP September meeting.

- Jim Thomas


> Begin forwarded message:
> 
> From: Joseph Myers <joseph at codesourcery.com>
> Subject: [SC22WG14.20399] tgmath.h narrowing macros with integer arguments
> Date: September 8, 2021 at 3:36:54 PM PDT
> To: <sc22wg14 at open-std.org>
> 
> The current C23 working draft defines the tgmath.h rules for narrowing 
> macros such as d32sqrt in a fairly ad hoc way that suffices for the types 
> in the main body of C23.
> 
> N2601, the current version of TS 18661-3 as Annex, has somewhat more 
> complicated rules to account for the new types in that Annex (these rules 
> differ in various ways from those in the original TS, to account for 
> clarification requests reported against that TS and to work better when 
> such macros are used with e.g. _Float32_t arguments).
> 
> Suppose you have
> 
> int n;
> 
> and call
> 
> d32sqrt(n)
> 
> which the main body of C23 would say calls the d32sqrtd64 function.  
> Applying the Annex rules would seem to treat the integer argument as if it 
> had type double, so resulting in undefined behavior.
> 
> For any case using only types and macros defined in the main body of the 
> standard, the Annex should not produce different results for which 
> function is chosen by an tgmath.h macro, and should not produce undefined 
> behavior for a case that is defined in the main body of the standard.
> 
> Thus, if d32sqrt(n) is intended to be allowed, I think the Annex needs to 
> say something about the case of decimal narrowing macros with only integer 
> arguments, to avoid ending up with double being chosen as the preliminary 
> type P.
> 
> A separate note on such macros with integer arguments: one example in 
> N2601 says that f32xsqrt(n) resolves to call f32xsqrtf64.  As I read 
> N2601, n is regarded as having type double, P is double, and if _Float64x 
> exists then f32xsqrtf64x is called.  (f32xsqrtf64 would have been correct 
> with the resolution to FPE CR#13.  If the change between that resolution 
> and C23 is as intended, then the example needs updating.)
> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com

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