On Thursday, October 9th, 2025 at 12:58 PM, Michel Morin via Boost <boost@lists.boost.org> wrote:
Michel Morin wrote:
As a baseline, I'd suggest running the dectest (for decimal32, 64, 128) at https://speleotrove.com/decimal/
decTest also indicates which status flags are expected to be raised, (though not all of them correspond to the IEEE 754 exception flags). I might just be missing something, but it seems that Boost.Decimal doesn't support FP exceptions. There may not be enough use cases for FP exceptions, but their support is mandatory for IEEE 754.
Are there any plans regarding FP exceptions?
The reason there is no support for them at this time is it's a tradeoff with the C++14 standard; I can't support std::feraiseexcept and constexpr at the same time. The latter is significantly more useful than the former. I believe they only times I worry about FP exceptions is when binding Boost.Math into python because Pybind11 will turn FP exceptions into hard errors. This also requires that the compilers and platforms support #pragma STDC FENV_ACCESS ON.
Possible implementation approaches include global/thread-local variables (e.g. C23), flag arguments (e.g. the intel library), or using a "context" argument (e.g. decNumber library).
Intel and decNumber aren't particularly ergonomic since the are C libs. For example Decimal64 + Decimal64 in Intel's lib becomes bid64_add(Decimal64, Decimal64, ROUNDING_MODE, &flag). Theoretically the same workaround for consteval contexts (__builtin_is_constant_evaluated()) that is used to set/query the rounding mode could be used when fenv access is allowed. Tracking my own global is another possibility, but then you lose the information in use cases such as with Pybind11 above. Matt