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

[Vincent Lefevre]

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.

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

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