[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression

["glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
"[Note: This document does not require an implementation to support the 
FENV_ACCESS pragma; it is implementation-defined (15.8) whether the pragma 
is supported. As a consequence, it is implementation-defined whether 
these functions can be used to test floating-point status flags, set 
floating-point control modes, or run under non-default mode settings. If 
the pragma is used to enable control over the floating-point environment, 
this document does not specify the effect on floating-point evaluation in 
constant expressions. — end note]"

So the C++ standard lets us choose what we want gcc to do in this case. The C
standard is of course more precise, but using its own definition of constant
expressions

http://port70.net/~nsz/c/c11/n1570.html#F.8.4
"1 An arithmetic constant expression of floating type, other than one in an
initializer for an object that has static or thread storage duration, is
evaluated (as if) during execution; thus, it is affected by any operative
floating-point control modes and raises floating-point exceptions as required
by IEC 60559 (provided the state for the FENV_ACCESS pragma is ''on'').366)

2 EXAMPLE

          #include <fenv.h>
          #pragma STDC FENV_ACCESS ON
          void f(void)
          {
                float w[] = { 0.0/0.0 };                  //   raises an
exception
                static float x = 0.0/0.0;                 //   does not raise
an exception
                float y = 0.0/0.0;                        //   raises an
exception
                double z = 0.0/0.0;                       //   raises an
exception
                /* ... */
          }

3 For the static initialization, the division is done at translation time,
raising no (execution-time) floating- point exceptions. On the other hand, for
the three automatic initializations the invalid division occurs at execution
time."

So Jakub's proposition makes sense, fold inexact operations when we have to
(and use default (nearest) rounding in that case, as long as we don't have
pragma fenv_round). Initializing a global (before main starts) also looks like
a place where folding could make sense, although it is less important.