[cfp-interest 3428] Re: constant expressions and floating-point exceptions

[Jim Thomas]

> On Apr 8, 2025, at 5:08 PM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> On 2025-04-08 15:29:17 -0700, Jim Thomas wrote:
>> Thoughts on [cfp-interest 3419] …
>> 
>> An implication that status flags are raised, or a statement that
>> they are not raised, at translation time seems inconsequential,
>> since C doesn’t provide a way to access status flags at translation
>> time.
> 
> OK. But something is not clear. A constant expression is allowed in
> a context where such an expression is not required. For instance:
> 
> int main()
> {
>  double x = 1 / 0;

1.0 / 0.0 ?

>  ...
> }
> 
> Here, a constant expression is not required. So 1 / 0 may be
> evaluated either at runtime or during translation as a constant
> expression. If evaluated at runtime, some flags may be raised.
> If evaluated during translation, is it required to raise these
> flags at runtime to get the same semantic as runtime (6.6p17)?

F.8.5 addresses this. I think without Annex F whether such operations raise flags at execution time is unspecified. 

> 
>> Another issue with 6.6 #17: The semantic rules for the evaluation
>> of constant expressions vs nonconstant expressions differ in that
>> constant expressions may (for implementation-defined or
>> indeterminant evaluation methods, per 5.3.5.3.3) be evaluated with
>> more range and precision.
> 
> I don't see why they would differ.

A cross compiler might not have the same floating-point arithmetic as one of its target machine. Translation-time evaluation with more range and precision than would be used at execution time is allowed by 6.6 #3. (However, such an implementation would have to define FLT_EVAL_METHOD to be a negative integer.)
> 
>> The evaluation methods characterized by the evaluation method macros
>> or resulting from evaluation method pragmas apply to both execution
>> time and translation time evaluations. Thus using extra range and
>> precision for translation time evaluation is not permitted under the
>> standard specified evaluation methods.
> 
> I don't understand why this would not be permitted. If I understand
> correctly, the same rules need to be used at translation time and
> at runtime (the same formats need to be used at translation time).

Right. The same rules apply. I wasn’t clear. By “using extra range and precision for translation time evaluation” I meant using more range and precision than would be used for execution-time evaluation.

These are not issues for decimal floating point which must conform to Annex F.

- Jim Thomas

> 
> -- 
> Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
> _______________________________________________
> cfp-interest mailing list
> cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest