Well: Basically what I was saying?

It's not a "bad" thing and nothing will break if you use it, you just need to be aware it does not adhere to the C spec.

In this case, the long double variant of the math functions (e.g. long double sinl(long double x)) are identical to the double versions (e.g. double sin(double x)) in msvcrt. As long as you're aware of this, there's no issues using it, except that you can't have a long double function from it (you'd have to implement it yourself or use another library that has it).

You can obviously use the other functions just fine (non-math or long double related).

Are you sure that C99 requires it for all architectures? Or only suggests it? I know all the world's a VAX, err ... AMD64, but is this reliable beyond that? Beyond GCC?

Anyways, MSVCRT.DLL is supposedly a "known .DLL", included as part of the OS, from something old like MSVC 6 or whatever. It wasn't meant to be reused by third-party compilers. In newer MSVC versions, there are tons of different runtime libraries, and I don't think some people had a redistribution license for bundling those. It's quite a mess, honestly.

So does that mean this didn't forcibly exist in C89 standard? IIRC, MSVC (again) didn't support anything beyond that until fairly recently (2013?), formerly preferring C++ (or even C#/.NET) instead. So maybe they support it in newer MSVC versions, who knows (but Googling implies no).

MinGW-64 is more active than MinGW these days, but IIRC, they added various shims to support C99 that MSVCRT didn't support directly. And of course Cygwin doesn't rely on that .DLL at all, so presumably "long double" is fully supported there.

But you'll have to test for yourself. Googling seems to imply bugs or lack of support. So don't get your hopes up. Just because it's "standard" doesn't mean that anyone cares, even compiler developers. If anything, that's normally how it goes, so expecting perfect compliance in compilers, even for standard languages, is being unfairly optimistic.

C standard doesn't even specify the floating point format itself. I simply meant that long double and the associated functions are standard and they are not the same as double, so msvcrt.dll does not adhere to the C spec.

Now, the ABI does define that long double maps to 80-bit x87 register, which is a different thing. "long double" and float formats are not "undefined behavior" but "implementation defined". The implementation here is the x86/x64 ABI.

Of course, an ABI may very well say that long double is the same thing as double on that platform, but that doesn't seem to be the case, even on Windows. And that's with Windows stupidly setting the x87 precision to 53-bits by default instead of 64-bits (can be easily changed, just issue a fninit instruction).

It might not adhere to newer C99, but it "probably" (mostly?) adheres to older C89.

I do seriously wonder about AVX-512 and whether that somehow supports "long double". In particular, Fortran probably has support somehow (even if only via library). Just a blind guess, I don't grok it. But Fortran people honestly might be the best ones to ask about such numeric capabilities.

Long-double, aka extended precision, aka 64-bit precision, is only available from the FPU instructions. It is the only place where the 80-bit data registers exist.

y=exp(x)
This does y=e**x, where x is in dword [store], and output is to dword [store]
Float has to be split because f2xm1 can only take -1 to +1 as an input.


fld dword [store] ; x
fldl2e ; log2(e)=1.442695040888963, x
fmulp st1,st0 ; x*log2(e)
fld st0 ; x*log2(e), x*log2(e)
frndint ; rint(x*log2(e)), x*log2(e)
fxch st1 ; x*log2(e), rint(x*log2(e))
fsub st0, st1 ; frac(x*log2(e)), rint(x*log2(e))
f2xm1 ; 2^frac(x*log2(e))-1, rint(x*log2(e))
fld1 ; 1, 2^frac(x*log2(e))-1, rint(x*log2(e))
faddp st1,st0 ; 2^frac(x*log2(e)), rint(x*log2(e))
fscale ; exp(x)=2^frac(x*log2(e))*2^rint(x*log2(e)), rint(x*log2(e)
fstp dword [store] ; rint(x*log2(e)
fstp st0 ; <empty>