D contains few features that make it not easy for LDC developers create a compiler that fully follows D specs. LDC developers have solved some of those, and maybe as LLVM improves few more may be solved in future. This lists most of them: http://www.dsource.org/projects/ldc/wiki/Docs#Violationsofthespecification
Like: - Inline assembler: For labels inside inline asm blocks, the D spec says "They can be the target of goto statements.", this is not supported at the moment. Basically, LLVM does not allow jumping in to or out of an asm block. We work around this for jumping out of asm by converting these branches to assignments to a temporary that is then used in a switch statement right after the inline asm block to jump to the final destination. This same workaround could be applied for jumping into inline assembly. - The D spec says that T[0] val; does not require storage but has an address. LDC currently allocates one bit for such a construct. So it may be better to think about such D features, and think if they aren't so important, so they can be removed to D specs, to help LDC to be a correct implementation of D1 (and in future D2). --------- But it can also be quite interesting to look at the situation from the opposite point of view. Currently LLVM offers some features (that are probably missing in the backend of DMD) that aren't present in D specs, but being them already implemented, adding them to D is cheap. For example: - inline asm intrinsics that allow smarter management of input-output CPU registers, this allows to write faster inline asm. - a way to inline (in a not safe way) functions that contain asm (this can be done by DMD too, I guess) - run time tests to find integer overflows (http://llvm.org/docs/LangRef.html#int_overflow ) - having a compiler that can be used as a dll, for example to compile code at runtime, to have a standard built-in D REPL (shell) to try D code interactively, and for some other things. This may turn out to be a strong advantage of D over C/C++, yet D developers seem uninterested to such big possibilities. - computed gotos (http://clang.llvm.org/doxygen/classclang_1_1GRIndirectGotoNodeBuilder.html ), that are useful to me too. - runtime stack protection with stack canaries (useful in nonrelease mode or for safeD) (-stack-protector). - analysis of the inheritance to de-virtualize class methods. - ways to state that pointer aliasing isn't happening. - llvm offers even built-in multi-precision integers. - support for optimization tricks like __builtin_expect() of GCC that sometimes are useful, in my programs too (this can probably be done in DMD too, but it's not present in D specs). - There are surely other things I have missed. Some of those things were suggested to be added to the D language, but they were refused also because they require work to be implemented (like the compiler as DLL, computed gotos and more), but now such refusals don't hold anymore because LLVM has such capabilities, and it's "just" a matter of defining a syntax, adding that to D specs, and then using them... So, while at the moment there's no LDC D2 compiler yet, D2 specs can take in account that LDC may eventually become the most used D compiler, so it can be much better to use the good things LLVM offers, instead of limiting D2 specs to just the capabilities of the old back-end of DMD :-) Bye, bearophile
