Just curious, but why couldn't you decide the rounding mode at compile time and pass the desired rounding mode as an argument to the compiler? Then you should be able to use something other than the default for constexpr evaluations. (Actually looking back at Marc's reply he says the standard doesn't like when constepr-ness varies, but what is the reason for that? If it had the same mandatory rounding options for all compilers and was well defined in the standard I don't see what the problem would be.) Also I found this proposal for adding "constexpr" to all of the functions in <cmath> to the standard. I'm not involved in influencing new C++ standards at all, but if either of you are maybe you can reach out to the guy who wrote this proposal and help him push it forward for C++23 :) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1383r0.pdf Thanks, Tim On Fri, Feb 14, 2020 at 6:09 AM Marc Glisse <marc.glisse@xxxxxxxx> wrote: > On Fri, 14 Feb 2020, Florian Weimer wrote: > > > * Jonathan Wakely: > > > >> I think it's very unlikely that constexpr support will decrease. The > >> trend has been in the opposite direction, to make every function in > >> the standard library usable in constant expressions. I heard a > >> suggestion to require implementations to add constexpr to <cmath> > >> functions just the other day. > > > > Many of these functions depend on global state such as the rounding > > mode. > > So does a+b for floating point numbers. > When the user is explicitly asking for constexpr, accepting to evaluate > all those in the default rounding mode and without exceptions sounds ok. > Doing it eagerly (say when initializing a non-constexpr variable) is a > different story. > It may also depend on -frounding-math, even if the standard doesn't like > it when constexpr-ness varies. > > -- > Marc Glisse >
