[reach2sayan]

On 32-bit Windows the Microsoft runtime's sqrt rounds to nearest whatever the rounding mode, so sqrt_down and sqrt_up return the same value, and sqrt of a point interval can miss the true root. The mode itself is set correctly: arithmetic follows it, and so do the x87 fsqrt and SSE2 sqrtsd instructions. 64-bit Windows is not affected.

On 32-bit MSVC and clang-cl, rounded_arith_std and rounded_arith_opp now compute the rounded square roots with fsqrt, as msvc_rounding_control.hpp already does for rint with frndint. Other platforms call sqrt as before.

test/sqrt_rounding.cpp checks sqrt_down and sqrt_up of both policies for float and double, and for long double where it has the format of double (as with MSVC).
For a non-square the two ends must differ; for an exact square both must be the exact root. x87 long double is skipped here because of a separate ordering bug, which #61handles. The same runtime bug is why the MSVC jobs fail on #61.
I also probed the other rounded operations that go through the runtime or a compiler helper - they all seem fine

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.51%. Comparing base (2bb1db2) to head (83f68cd).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop      #64      +/-   ##
===========================================
+ Coverage    82.41%   82.51%   +0.10%     
===========================================
  Files           23       23              
  Lines          995     1001       +6     
  Branches       409      410       +1     
===========================================
+ Hits           820      826       +6     
  Misses         167      167              
  Partials         8        8              

Files with missing lines	Coverage Δ
include/boost/numeric/interval/rounded_arith.hpp	100.00% <100.00%> (ø)

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2bb1db2...83f68cd. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Lastique]

I think, you need to check for the _M_IX86_FP value here and select between x87 and SSE2 implementations. Otherwise, you're forcing x87 when the rest of the program is using SSE2. You can use SSE2 intrinsics to calculate the sqrt. And we should probably add separate CI jobs for 32-bit x86 with /arch:IA32 and /arch:SSE2.

Also, since you're working around a standard library issue, you probably need to check BOOST_DINKUMWARE_STDLIB here.

[reach2sayan]

About BOOST_DINKUMWARE_STDLIB - I read it needs to applied when using the c++ stdlib, but here it was using the C Runtime? there was a clang windows failure as well?

[Lastique]

Yes, BOOST_DINKUMWARE_STDLIB indicates Microsoft's C++ standard library. We don't have a macro specifically for the C standard library, C++ library is the closest we have. The idea is that if there is a compiler that uses the same C runtime but does not pretend to be MSVC then it should be also affected. However, to my knowledge, all compilers using MS's C++ standard library do pretend as MSVC. MinGW gcc, which uses libstdc++ and some parts of MS's C runtime, appears to be passing in CI. I think, this is because it directly generates x87 and SSE instructions for sqrt instead of the C library calls. So this point is probably moot.

[Lastique]

It is better to use an asm block here, i.e.:

__asm
{
    ...
}

Otherwise, the compiler may reorder the individual __asm statements and the surrounding code and potentially clobber the FPU stack in between the instructions.

Same for the double version.