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)