MinGW-w64 runtime library inclusion (Clang-compiled) for proper Win64 support?

[kink]

Hi guys,

first of all, a big fat thank-you to David & Kai for your 
dedication, it's looking good and getting better!

I recently synced the LDC sources, compiled it on my Win8 x64 
system using MSVC 2012 and latest LLVM 3.4 sources and ran a few 
tests (the whole procedure has gotten even less painful, thank 
you very much Kai!). I soon figured out that printing reals still 
results in garbage, e.g.:

<code>
import std.stdio: writefln;
import std.conv:  to;

int main()
{
     real r = 2;
     writefln("%%g (double): %g", cast(double) r);
     writefln("%%g:          %g", r);
     string s = to!string(r);
     writefln("to!string:   %s", s);

     s = "2.0";
     r = to!real(s);
     writefln("%s parsed as %g", s, cast(double) r);

     return 0;
}
</code>

outputs something like:

%g (double): 2
%g:          3.95253e-323
to!string:   4.94066e-324
2.0 parsed as 2

The problem is that the underlying calls to MSVCRT's snprintf() 
pass reals as unsupported 80-bit 'long doubles' (MSVCRT doesn't 
support this type at all), and yes, I know the Wiki page mentions 
broken reals support. ;)

So I was wondering about how to tackle this task, considering 
Phobos' std.math strongly encourages using the real type. It's 
nice that we exploit LLVM intrinsics, LLVM assembly, D assembly 
and D workarounds in LDC, DRuntime and Phobos to circumvent some 
issues caused by Microsoft's shameful missing C99 support in 
their runtime (in general, math.h just being an example). But as 
you know, there are still missing functions (=> linking issues), 
broken implementations and bugs.

My idea was to include the MinGW(-w64) runtime library, since 
afaik MinGW mainly addresses exactly Microsoft's lacking 
compatibility. I really like LDC's ability to output 
MSVC-compatible objects and the usage of the MS linker, i.e. the 
pretty smooth integration into the Visual-Studio-ecosystem, and 
don't want to use LDC based on MinGW(-w64) and its object-file 
format.

I first tried to compile a few modules of the MinGW-w64-CRT 
source using VC 2012. Obviously loads of issues with incompatible 
keywords, assembly syntax etc. arised and the 'long double' type 
simply maps to 'double' (you may very well call that cheating), 
so there's no way to get that to work unless coding everything in 
naked assembly.

Then I tried to compile a few modules with Clang (latest source & 
latest LLVM, compiled painlessly with MSVC 2012 as well). It 
seems to swallow MinGW's code quite well - nice. I succeeded in 
linking a dummy DLL (compiled with Clang and linked with MSVCRT; 
Clang is supposed to have troubles with Microsoft's C++ headers, 
but the C headers should work) to a D executable (compiled with 
LDC, of course). So imho with MinGW's runtime (or a trimmed-down 
version thereof) as additional (default?) static/dynamic library 
we'd have a nice fallback for missing functions.

Unfortunately, there are ABI issues, even a minimalistic

__declspec(dllexport) int foo(int a) { return a + 3; }

in the dummy library returns garbage in x64 mode, in both LDC and 
MSVC executables - but works in x86 mode, at least when called 
from a dummy MSVC executable (my LDC is on a strict diet and is 
allowed to spit out x64 code only). So Clang apparently doesn't 
support the Win64 ABI yet, *sigh*.

Anyway, I'd like to know what you think about including a (most 
likely tailored) MinGW runtime library, compiled with Clang, with 
LDC for Windows to obtain max compatibility.