[Cfp-interest] [Fwd: (SC22WG14.12589) Comments on N1591 (binary floating point)]

[Jim Thomas]

Joseph,

Thanks for your review and comments. Please see below.

-Jim


> 
> 
> From: "Joseph S. Myers" <jsm at polyomino.org.uk>
> Subject: (SC22WG14.12589) Comments on N1591 (binary floating point)
> Date: January 23, 2012 12:56:45 PM PST
> To: sc22wg14 at open-std.org
> 
> 
> A few comments on the N1591 binary floating point draft:
> 
> (a) There are references to both __STDC_IEC_60559__ (in several places) 
> but also __STDC_IEC_60559_1__ (clause 5).  I suppose only one macro name 
> was intended.

Right. __STDC_IEC_60559_1__ was intended.
> 
> (b) The constant rounding modes specification (7.6.2) refers to "Any call 
> made through a function pointer".  The semantics specified by the C 
> standard are that *all* calls to a function (as opposed to a macro) are 
> through a function pointer; the function designator is converted, 
> explicitly or implicitly, to pointer to function type, before it is used 
> in a call.

Please provide a reference for the C standard specification.

> 
> I suppose the intent is that "sin (x)" gets the constant mode, but
> 
>  double (*fp) (double) = sin;
> 
>  fp (x);
> 
> doesn't.  

Right.

> But what about "(sin) (x)" or "(*sin) (x)" - or for that matter, 
> "(((sin))) (x)" or "(***sin) (x)", or the example type-generic cbrt macro 
> given in C11 as an example of _Generic?  Do those - in particular, the 
> first with parentheses - use the constant or the dynamic mode?  Does "sin 
> (x)" get the constant mode in all the following cases: (i) <math.h> 
> included, sin possibly defined as a macro there; (ii) <math.h> included 
> but with "#undef sin" following to ensure a function is called; (iii) 
> <math.h> not included, sin declared directly in accordance with the C 
> standard specification that "Provided that a library function can be 
> declared without reference to any type defined in a header, it is also 
> permissible to declare the function and use it without including its 
> associated header."?

We hadn't considered all these cases. I believe our intention would be for (i) and (ii) to get the constant mode. Not sure about (iii).

> 
> (c) Should <tgmath.h> be included in the headers for which calls get the 
> constant mode - that is, should calls to the type-generic macros there get 
> the constant mode?  Whether they do or don't may affect the details of the 
> implementation (cf. the point in (b) above about _Generic).

<tgmath.h> didn't make it into the draft by the mailing deadline. It is in the editing draft now (see below), though without an answer to your question about constant modes. <tgmath.h> invocations should get the constant mode. 

> 
> (d) Should <wchar.h> be included in the headers for which calls get the 
> constant mode?  It would seem odd for printf to follow the static 
> direction but wprintf to follow the dynamic direction; similarly strtod 
> and wcstod.

Yes, it should be included.

> 
> (e) Why do all the getpayload functions listed for F.10.13.1 take the 
> operand NaN as const double * but return the payload in differing types - 
> shouldn't the two types match?  Likewise, shouldn't the setpayload types 
> vary between the functions for F.10.13.2 and F.10.13.3 rather than all 
> being double?  The payload of a NaN is "encoded in the p-2 least 
> significant bits of the trailing significand field" - that is, all except 
> the first bit that distinguishes quiet and signaling NaNs - so the payload 
> of a long double NaN may not be representable in double.

Typos. The types should match up, as you suggest. 

> 
> -- 
> Joseph S. Myers
> jsm at polyomino.org.uk
> 
> 
> 

16  Type-generic math <tgmath.h>

The following suggested changes to C11 enhance the specification for type-generic math macros to accommodate functions in Part 1 of this Technical Specification.

Suggested changes to C11:

In 7.25 #2, change:

For each such function, except modf, there is a corresponding type-generic macro.

to:

For each such function, except modf, setpayload, and setpayloadsig, there is a corresponding type-generic macro.

In 7.25 #3, replace:

Use of the macro invokes a function whose generic parameters have the corresponding real type determined as follows:

with:

Except for the macros for functions that round result to a narrower type (7.12.14), use of the macro invokes a function whose generic parameters have the corresponding real type determined as follows:

In 7.25 #5, include in the list of type-generic macros: roundeven, nextup, nextdown, fminmag, fmaxmag, llogb, fromfp, ufromfp, fromfpx, ufromfpx, totalorder, totalordermag, and canonicalize.

After 7.25 #6, add the paragraph:

The functions that round result to a narrower type have type-generic macros whose names are obtained by omitting any f or l suffix from the function names. Thus, the macros are:


fadd

dadd

fsub

dsub

fmul

dmul

fdiv

ddiv

ffma

dfma

fsqrt

dsqrt


 

All arguments are generic. If any argument is not real, use of the macro results in undefined behavior. If any argument has type long double, or if the macro prefix is d, the function invoked has the name of the macro with an l suffix. Otherwise, the function invoked has the name of the macro (with no suffix).

In 7.25 #7, append to the table:

fsub(f, ld)              fsubl(f, ld)

fdiv(d, n)               fdiv(d, n), the function

dfma(f, d, ld)        dfmal(f, d, ld)

dadd(f, f)               daddl(f, f)

dsqrt(dc)               undefined behavior

> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20120123/58ffff3b/attachment-0001.html