[Bug c++/91099] New: constexpr vs -frounding-math

[glisse at gcc dot gnu.org]

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

            Bug ID: 91099
           Summary: constexpr vs -frounding-math
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

constexpr double d = 1. / 3.;

currently fails to compile with -frounding-math. This behavior makes sense: we
do not know in what direction to round. However, -frounding-math is about the
dynamic rounding mode, while the above expression must be evaluated at compile
time, where there is no dynamic rounding mode (pragma fenv_round from C2a may
eventually provide a way to specify a relevant rounding mode). An alternative
to refusing to perform any inexact math at compile time would be, when the
computation is absolutely required to be performed at compile time, to use the
default rounding mode.

I tried adding:

  Save<int> save_frm(flag_rounding_math, flag_rounding_math &
!ctx->manifestly_const_eval);

near the beginning of cxx_eval_constant_expression, where Save is

template<class T> struct Save {
    T& ref; T old;
    Save(T& t, T newval): ref(t), old(t) { ref = newval; }
    ~Save() { ref = old; }
};

which kind of works on trivial examples, but is defeated by constexpr-caching
if we change flag_rounding_math in the middle of a translation unit: if we have
previously (-fno-rounding-math) managed to fold a function computing 1./3, we
blindly reuse the result even if we now have -frounding-math. I don't know if
it would be acceptable to say that -frounding-math may not be changed in the
middle of a translation unit. (for pragma fenv_access, I currently think I
should use a different flag)