`<complex>`: `_LDtest` looks quite questionable

[frederick-vs-ja]

#1316 added _LDtest to handle Intel 80-bit long double, which is normally unsupported by MSVC STL.

But the uses of _LDtest don't seem right according to MSVC STL's function definition:

STL/stl/src/xldtest.cpp

Lines 10 to 12 in 313964b

	_CRTIMP2_PURE short __CLRCALL_PURE_OR_CDECL _LDtest(long double* px) noexcept { // categorize *px -- 64-bit
	return _Dtest(reinterpret_cast<double*>(px));
	}

With strict aliasing violation ignored, _LDtest effectively takes the initial 64 bits of a long double, then treats the part as a double value, and then inspect such a value. This doesn't properly work when long double and double have different formats.

(Originally posted by @statementreply in #2073 (comment))

I wonder whether we really need to inspect the value representation here. If any case, can't we use usual comparison for 80-bit long double (x != x for NaN, x > max() || x < -max() for Inf)? @simmse

Moreover, it seems that _LDtest, _LSinh, and _LCosh are unnecessary (and can be removed in vNext) as we can dispatch to functions for double.

[simmse]

To address the comparison aspect, from the 1.88 Boost C++ library, cstdfloat_cmath.hpp, the code below is inside the pown function.

               const bool isnan = (x != x);
               const bool isinf = ((!isneg) ? bool(+x > (std::numeric_limits<float_type>::max)())
                  : bool(-x > (std::numeric_limits<float_type>::max)()));

As far as _LDTest is concerned, that is part of the Microsoft runtime. Searching the start of the VC directory sub-tree from VIsual Studio 2022, 17.14.4, there are 17 120 hits in 565 files. Not a good candidate for removal. Please take into consideration commercial software development. Many high precision software products exist that are built with Microsoft Visual Studio and Intel oneAPI C++ on Windows. Companies pay a lot of money to maintain existing functionality in development tools and the supporting libraries. Removing _LDTest, _LSinh, _LCosh "just because" makes no sense.

In case it is not known, the more recent language standard enhancements modifies floating point types to support 128 bit floating point precision. Both C23 and C++23 libraries support float128_t Fixed width floating-point types (since C++23), Standard library header (C++23), P1467R9 Extended floating-point types and standard names, For C - WG 14 N2341.

[StephanTLavavej]

But the uses of _LDtest don't seem right according to MSVC STL's function definition:

My understanding is that users of 80-bit long double are replacing our definition of _LDtest, not using the one that MSVC's STL provides.

can't we use usual comparison for 80-bit long double (x != x for NaN, x > max() || x < -max() for Inf)?

My understanding is that x != x won't work under /fp:fast although I haven't looked at this lately.

I don't know how hostile /fp:fast is to infinity comparisons, but the doc page says that it can be.

As far as _LDTest is concerned, that is part of the Microsoft runtime. Searching the start of the VC directory sub-tree from VIsual Studio 2022, 17.14.4, there are 17 120 hits in 565 files. Not a good candidate for removal.

Because we control VC's usage, we can absolutely remove internal functions that are widely used internally, and have done so numerous times in the past.

In the specific case of _LDtest, which is non-Standard, undocumented, and formally unsupported, we are currently following our unofficial policy of not gratuitously breaking existing usage of Intel 80-bit long double, even though that is a mode that we neither test nor provide support for, in a compiler that we neither test nor provide support for. (And we don't extend this to new code manipulating long double.) We reserve the right to remove such legacy code in a future ABI-breaking "vNext" release of the libraries.

Both C23 and C++23 libraries support float128_t

This is not entirely accurate. C++23 allows, but does not require extended floating-point types to be supported. Currently, MSVC has chosen not to support any extended floating-point types. Therefore, we were able to implement WG21-P1467R9 tracked by #2956 with minimal changes.

This may or may not change in future versions of MSVC.