[Cfp-interest 2819] Re: CFP review of TS-5 revisions

[Jim Thomas]

> On Aug 14, 2023, at 11:01 AM, Fred J. Tydeman <tydeman at tybor.com> wrote:
> 
> On Sun, 6 Aug 2023 08:58:54 -0700 Jim Thomas wrote:
>> 
>> https://wiki.edg.com/pub/CFP/WebHome/cfp5r-20230806.pdf
> 
> Fred's comments on 18661-5r
> 
> References to 'page' are printed page numbers.
> 
> 5.1 page 2, line 9:  Is there a problem with freestanding conformance
> and the use of <math.h> for the #pragmas?

Not that I see. What are you thinking of? Rajan?

> 
> 7.1 page 4, line 4 and line 31.  If width is not supported, I think it
> should be a constraint violation (that ends translation).

Are there constraint violations in the C Library? I don’t think C ever requires ending translation.

We might suggest as recommended practice that the implementation issue a diagnostic message.
 
> 
> For both FP_FLT_EVAL_METHOD and FP_DEC_EVAL_METHOD, what are their
> conditions at the start of translation?  Need to know so can restore
> at end of compound statement.  That is:  The default state of the pragma is ...

For FP_FLT_EVAL_METHOD we say "DEFAULT designates the implementation’s default evaluation method (characterized by the FLT_EVAL_METHOD macro)”. For FP_DEC_EVAL_METHOD we say "DEFAULT designates the implementation’s default evaluation method (characterized by the DEC_EVAL_METHOD macro)”. Isn’t that sufficient?

> 
> 7.3 page 5, line 3.  Why in <math.h> instead of <float.h>?

Good question. To this point TS-5 hasn’t extended <float.h>. I was thinking that the effective evaluation method macros would be used only in conjuction with the evaluation method pragmas which are in <math.h>.

> 
> 8.0 page 6, line 30. To me, "operators" are part of user code.

This is talking about implementation code used to implement an operator.
> 
> For all of the 8.* pragmas, what are their conditions at the start of
> translation?  Need to know so can restore at end of compound
> statement.  That is:  The default state of the pragma is ...

They all specify the default. E.g. in 8.2 there is

where on-off-switch is one of
ON – allow application of the associative laws
OFF – do not allow application of the associative laws
DEFAULT – “off”

> 
> Why <math.h> for these 8.* pragmas?

CFP discussed and resolved this over several recent meetings. The other choices we considered were <fenv.h> and <float.h>. 

The 8.* pragmas primarily control the semantics of expression evaluation, not the dynamic floating-point environment which is the subject of <fenv.h>. We didn’t want to expand the concept of the floating-point environment to include the constant modes controlled by these pragmas. 

At this time <float.h> doesn’t have any pragmas. It’s primarily about values in types, not arithmetic (though the evaluation method macros are about the format of arithmetic results).

<math.h> already has the FP_CONTRACT pragma for optimization control. It also has the _t types which aren’t related to math functions. Although adding the pragmas expands <math.h> to include more arithmetic features (not just math functions), it seems like the best option. 
 
> 
> 8.5 Do we need to anything about the sign of the zero (same as sign of
> subnormal or unspecified)?

Hmm. IEEE 754 didn’t mention this in its list of optimizations that might be allowable by attributes, though the list was not intended to be complete. Do you know of any implementations that have controls to allow optimizations involving the sign of zero? E.g. that allow ignoring the sign of zero inputs, or that make unspecified the sign of zero outputs? I’d be reluctant to add something like this without a clear need, particularly at this stage. 
> 
> 8.6, 8.7 Should some words be added on how is these are subset of
> FP_CONTRACT?  

I don’t understand the question.

> Or, perhaps, have 8.8 come before 8.6 and 8.7.

What problem would that solve?

> 
> 10.1 page 16, line 7:  Do we need to list all the logarithm functions?

Yes, other bullets in the subclause give such details. Some of the bullets list the subclauses of clause 7 for the relevant functions. But the exceptions are specified in F.10, not 7. I suggest we add references to the appropriate subclauses of F.10. Making the bullets consistent isn’t straightforward because in some cases the references to subclauses of 7 are helpful for identifying the functions and in some cases references to subclauses of F.10 would be sufficient. I’ll try to draft something and distribute it. We should at least list the logarithm functions or their subclauses.

> 
> 10.1 page 16, last line:  Should something like this be added:
> The default state of the pragma is DEFAULT FE_ALL_EXCEPT.

What exactly is missing?

One of the actions for the pragma is

—	default exception handling (as specified in IEC 60559).
		DEFAULT

By “default state of the pragma” I assume you mean the state (of whatever the pragma controls) in the absence of the pragma, which is specified in Annex F and IEC 60559.

> 
> 10.1 page 20, line 18:  Shift to left to match other #pragma.

Yes.

> 
> 10.1 page 21, table: Do not understand why f[0] is not 2.0 for
> try-catch case.  

The relevant specification for CATCH says "if the execution of the associated compound statement to completion (without the jump) would at any point modify an object, the value of the object is indeterminate”.

> Page 22 lines 9-10 have some words.  Perhaps, we need
> to add:  Sequence points may not be honored for try-catch.

That statement is too sweeping. If the designated exceptions don’t occur then sequence points are honored. I would assume the TS would be understood to mean sequence points are honored except where the TS says something to the contrary.

- Jim Thomas

> 
> 
> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (702) 608-6093      Vice-chair of INCITS/C (ANSI "C")
> Sample C17+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.