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

[Jim Thomas]

> On Apr 9, 2025, at 3:27 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
> 
> On 2025-04-08 20:47:54 -0700, Jim Thomas wrote:
>>> 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 ?
> 
> Yes, of course (it was starting to be late...).
> 
>>> ...
>>> }
>>> 
>>> 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.
> 
> OK, but note that without Annex F, I think that 1.0 / 0.0 is actually
> undefined behavior. However, one can take another example:
> 
> int main()
> {
>  double one_third = 1.0/3.0;
>  ...
> }
> 
> and whether the inexact flag should be raised without Annex F.
> IMHO, the standard should be clear on this point.

C (without Annex F) doesn’t specify how floating-point operators affect status flags. Risks with doing that would include (i) having a C model for floating-point exceptions that is different from the Annex F (IEEE 754) model, and (ii) making existing implementations non-conforming.

> 
>>>> 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.
> 
> This is not directly related to the extra range and precision: a
> difference may also be the case for the native types, in particular
> "long double" in practice (one can see double, double-double,
> x86 extended precision, and binary128). I think that it is rather
> obvious than the arithmetic of the target machine needs to be
> emulated.
> 
>> 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.)
> 
> Yes, if both platforms behave differently for the evaluation method,
> and no emulation is done by the compiler. However, I think that it is
> better to have FLT_EVAL_METHOD set to a specified value and emulate
> the arithmetic of the target machine.

I agree that’s the better implementation choice.

- 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

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