Merge cppmangle from upstream 2.067

[ibuclaw]

Whilst still maintaining some compiler-specific differences that are not resolved/not part of 2.067.

• Static arrays are still mangled as pointers to support va_list on x86-64
• Vendor-specific types are not turned into ICEs (for the moment).
• ifdef out all ugly OSX hacks that DMD does.

This should be enough to support building ddmd, after some small fixups, such as compiler switch differences, using -fversion=GC and working around the fact that yl2x is a dmd-specific intrinsic and not available for use in CTFE.

I had already built ddmd with gdc a month back and verified that the resultant compiler passes the D2 testsuite and unittests.

@MartinNowak - is this of use to you?

[jpf91]

@ibuclaw Thinking about windows support:
The MinGW g++ compiler uses the Itanium ABI. So if we want to mix g++/gdc we can use the Itanium name mangler. But can we also interface to VisualC++ code with the VisualCPPMangler? Do you have any insight in MinGW ABI compatibility? Documentation about this issue is scarce. The standard answer is MinGW/VisualC++ are not compatible. Of course those can't be compatible as g++ uses different name mangling, but that doesn't have to apply to gdc. So the question is what's left for ABI compatibility.

• Exception handling: 64 bit uses SEH so that should work? 32bit SEH is on the MinGW wishlist but not implemented.
• Runtime: MinGW uses the standard msvcrt, afaics.
• Object file format, C ABI: AFAICS should be compatible
• Debug info: different (pdb/dwarf) but can coexist
• Is there any information about function call / parameter passing ABI / calling conventions for VisualC++? EDIT: Seems to be standard Windows calling convention which is supported by MinGW.

[ibuclaw]

But can we also interface to VisualC++ code with the VisualCPPMangler?

Almost non-existent, I guess.

Even if mangling were the same there are other problems:

• Structure alignment.
• Exception handlers (Thrown exceptions in one will not be caught by the other).
• Memory model (One simply does not malloc in GNU and free in MSVC)

I think it's much safer for us to just mangle in itanium always. That way the user gets a hard "no" at link time, rather that us making some simple code work and let the nightmare runtime issues emerge when people try more complex applications.

[jpf91]

Exception handlers (Thrown exceptions in one will not be caught by the other).

That could be difficult indeed, I don't know the actual GCC SEH implementation.

Structure alignment.

MinGW claims to be ABI compatible for C. The only Exception I know is the -mms-bitfields flags, but it is enabled by default since GCC 4.7.

Memory model (One simply does not malloc in GNU and free in MSVC)

I don't see why this wouldn't work. MinGW uses the standard microsoft runtime and this should include malloc. The only problem is that MinGW DLLs link an old version of the runtime but this can be changed. So in the worst case you might end up with two microsoft runtimes linked in, but the same thing might happen if you have two DLLs compiled with different VisualC++ versions. And you should never use malloc/free across DLL boundaries, exactly for this reason ;-) MS really screwed this up: http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell

I think it's much safer for us to just mangle in itanium always. That way the user gets a hard "no" at link time, rather that us making some simple code work and let the nightmare runtime issues emerge when people try more complex applications.

That's probably right. I might still try it though, just for fun ;-)

[jpf91]

LGTM. Ready to merge?

[ibuclaw]

Yep, it's just cherry-picked from upstream, so one less file to merge later.