cc @asmorkalov This can prevent potential test failure in 5.x.

cc @mshabunin

@amane-ame , please resolve merge conflict.

@mshabunin Done.

roundeven, roundevenf, roundevenl are available since C++23. Not sure if it's universal solution. @mshabunin What so you think?

My performance results perf.zip

@amane-ame I suggest you to solve conflicts with the following cli git commands instead of the GitHub webpage tool to ensure that your commits are continuous in your branch.

git remote add upstream https://github.com/opencv/opencv
git fetch upstream
git rebase upstream/4.x

@fengyuentau Uh, rebase will mess up the order of commits and comments in PR, because GitHub sorts them by commit date. If you are okay with this, it's fine.

roundeven, roundevenf, roundevenl are available since C++23. Not sure if it's universal solution. @mshabunin What so you think?

Let's restore rint + fesetround - it should be thread-local. Perhaps we can try to reduce number of rounding-mode switching by wrapping whole table initialization in fesetround calls.

See also: https://en.cppreference.com/w/cpp/numeric/fenv

@mshabunin I can use std::remainder instead of roundeven and std::rint. It's fenv irrelevant.

@amane-ame , how does it affect performance? Or is the table initialized just once and it doesn't matter much?

I thought that something like this would be good from both performance and safety standpoints:

int old_mode = fesetround(...);
// init whole table using rint
fesetround(old_mode);

@mshabunin std::remainder should not have any performance impact, since LabTable will only be initialized once in a process.