Also adds the CMake infrastructure to compile and link the D source files.
The build is partially broken:
- A few files in Phobos and druntime do not build
- MSVC build is broken because of unresolved symbols involving reals
* x86: Return most POD aggregates <= 8 bytes in registers
* For extern(D), as in official Win32 D ABI specs [previously: sret]
* For all other calling conventions too, except for Linux and NetBSD
[previously: OSX and MSVC only]
* MSVC++ and extern(C++): treat structs with constructors as non-POD,
for both x86 and Win64 ABIs
* Win64: Pass and return magic C++ structs directly as LL aggregates,
rendering MSVCLongDoubleRewrite obsolete
* x86: Fix regression introduced by previous commits wrt. passing the
last struct argument in EAX register
__c_long and __c_ulong have already been passed directly as LL structs
containing a single 32-bit value, i.e., as 32-bit scalars in the end.
__c_long_double on the other hand was rewritten to a 64-bit integer as any
other 64-bit POD struct, and so passed in a GP register instead of an XMM
register.
And for sret args too, except for MSVC targets.
At least on Win64, the sret align attributes lead to ICEs for std.bitmanip
and std.uni (release only), when computing the known alignment in the LLVM
inliner pass:
Assertion failed: I->getParent()->getParent() ==
Q.CxtI->getParent()->getParent() && "Got assumption for the wrong function!",
file C:\LDC\llvm\lib\Analysis\ValueTracking.cpp, line 711
0.15.1 used stdcall convention everywhere. But the ABI change in 0.15.2
requires use of the C calling convention for variadic calls on x86
because the stdcall convention does not support vararg functions.
Solution is to check the llvm::FunctionType if the function has varargs.
This commit also makes the C calling convention the global default
because according to the LLVM documentation the fastcc convention used
for D linkage does not support varargs.
This fixes issue #1000.
I've decided to use a consistent scheme here - types are returned the same
way as they are passed as arguments. So cfloat as 64-bit struct in RAX,
cdouble/creal and 80-bit real/ireal as types > 64 bit via sret.
MS allows using the x87 stack, but there are no official guidelines as
they don't use x87 at all.