jpf91
GDC (and LDC, the LLVM D compiler) use the frontend (lexer, parser,semantic) provided by the DMD reference compiler. GDC and LDC then map the AST produced by the frontend to something GCC and LLVM understand.
The DMD frontend has always been boost licensed. So the licensing question is valid here as we'll include boost frontend code into GCC. But I don't really have an answer to the question ;-)
I think this should be working. You don't have to 'mix source code', you can implement YourDClassType in D and use it in C++. You simply have to write a C++ header describing the class. Then write a D file describing the external C++ sdt::vector<YourDClassType> file and link everything together.
Not sure if anybody actively tested this though ;-)
Back then we had a shell script hack that was called by the GCC configure script and parsed the target triplet to set these versions.
Fortunately that's long gone and we now simply add some D specific code to the platform configuration files in gcc/config/ . The shell script hack would have never passed the GCC review ;-)
We require some per-target integration to provide correct version(ARM), version(linux) statements in D code and we need to know the size of a mutex on the target system. Iain is currently rewriting this code here: https://github.com/D-Programming-GDC/GDC/pull/500
However, we already provide and the new, rewritten code will continue to provide this integration for many targets. For example, all debian targets should be working: https://packages.debian.org/experimental/gdc
The main problem with architecture support is porting the runtime library and phobos. Here ARM is supported, MIPS and PPC has seen some work from LDC devs but making this work fully on GDC might require some small changes, MinGW is broken (and was never fully supported).
One caveat thought is that all D compilers mainly target 32 or 64 bit systems. So things won't just work without changes for 8bit targets, although we've seen proof of concept D code on 8bit and 16bit CPUs as well.