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

[Fred J. Tydeman]

On Tue, 15 Aug 2023 11:01:55 -0700 Jim Thomas wrote:
>
>
>
>> 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?

Those programs cannot access the floating-point exception flags
since they cannot do #pragma STDC FENV_ACCESS ON 
(C23 4. Conformance: Paragraph7)
But, I guess they can still use the other pragmas.


>> 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.

Not that I can see for either.

>We might suggest as recommended practice that the implementation issue a diagnostic message.

OK


>> 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?

Probably.

>> 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>.

May not matter if we can get pragmas independent of headers.


>> 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.

But, the operator is in user code.  


>> 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"

I see your point.


>> 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. 

Some older versions of ARM left the sign of zero from a flushed subnormal
be unspecified (or implementation defined).  
Later versions made it be the sign of the subnormal.


>> 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?

Seems to me that the superset control should come before the subsets.
Page 11, lines 17 & 18.


---
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.