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

[Jim Thomas]

> On Aug 15, 2023, at 1:47 PM, Fred J. Tydeman <tydeman at tybor.com> wrote:
> 
> 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

How about adding at the end of clause 7 …

Recommended practice
If the value of width appearing in an evaluation method pragma (7.1, 7.2) is not supported, the implementation is encouraged to 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?
> 
> 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.

Suppose the implementation uses a software routine to compute division. And suppose a divide (/) operator is under the effect of 

#pragma STDC FP_ALLOW_VALUE_CHANGING-OPTIMIZATION ON

The (static mode) pragma does not apply to the code used to implement divide, whether or not the divide code is inlined. This is just a corollary of the principle that inlining code does not change its behavior. 

- Jim Thomas

> 
> 
>>> 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 <mailto: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 <http://www.tybor.com/>
> Savers sleep well, investors eat well, spenders work forever.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230816/c56b53e0/attachment-0001.htm>