cmath intrinsic functions missing for double

[jbrezina]

I'm using std::round from cmath header file. I want the __round intrinsic function to be used, but I could not find any function supporting just double parameter, there is only long double version which casts the parameter to double anyways.

_NODISCARD _Check_return_ inline long double round(_In_ long double _Xx) noexcept /* strengthened */ {
#if _HAS_CMATH_INTRINSICS
    return __round(static_cast<double>(_Xx));
#elif defined(__clang__)
    return __builtin_roundl(_Xx);
#else // ^^^ defined(__clang__) / intrinsics unavailable vvv
    return _CSTD roundl(_Xx);
#endif // ^^^ intrinsics unavailable ^^^
}

To use the version with __round intrinsic function I have to cast the parameter to long double otherwise the old C version from math.h (corecrt_math.h) header file is used, which is much slower.

Is there any reason for that or am I doing anything wrong?

const double number{ -0.493 };

const auto result{ std::round(number) }; // uses C function from math.h
const auto result{ std::round(static_cast<long double>(number)) }; // uses std::round from cmath with __round intrinsic function

I found this issue Use ceil/floor/round/etc. intrinsics so I don't know if this is still in progress, but it's been 4 years since the issue was opened..

[frederick-vs-ja]

The overload for double is provided by UCRT so it's unfortunate that we can't achieve optimization for it in MSVC STL.

Perhaps we can report this on Developer Community (DevCom). But UCRT seems somehow "frozen" and one of my previous report for conformance bugs was closed for low priority.

[StephanTLavavej]

While in general we shouldn't expect major changes from the UCRT, Casey Carter (@CaseyCarter) is currently looking into this area. Additionally, since coordinated changes with the UCRT will almost certainly be necessary to implement C++23/26 constexpr for <cmath> (#2530 and #3789), we're going to have to overhaul this area anyways, so it's the one place where we can reasonably expect UCRT improvements.

[StephanTLavavej]

This is probably fixed by the "header duplexing" in #6413 but I'll think about it later.