The generic ABI works well with PPC64 except for LLVM PR 14779.
(http://llvm.org/bugs/show_bug.cgi?id=14779)
The new ABI infrastucture is based on the UnknownTargetABI. The
PPC64 specific parts coming soon.
In many parts the DMD frontend assumes a little endian CPU. In some
parts there are checks for endianess but they are incomplete and the
used definition is wrong. (Test for endianess will be removed in dmd
2.062.)
In this commit I add the required #if's and also add a CMake test for
endianess because there is no single compiler definition to check for.
The commit itself should be fine, but the more aggressive
inlining being done on the GC code (due to the gcbits functions
being in available in gc.gcx) seems to have uncovered a
misoptimization bug in LLVM (at least in 3.2) on x86, leading to
various unit tests failing in relase mode.
This reverts part of commit f02e4b1925.
A "statementsToo" flag was added to DMD, which disables inlining
of pretty much any functions that actually return a value – set it
to false for our purposes.
The other parts of the diff are just cosmetic.
The code to generate a constant string is too complex. Just use the
method provided by LLVM.
The complexity was introduced during a LLVM refactoring....
This reverts commit c4adbedcc, which would have fixed the
problem at its roots, but caused strange template function
attribute inference failures in D-YAML, presumably due to
the different order of semantic3 execution on the templates.
On a PowerPC target the datatype real is mapped to PPC 128bit doubledouble type.
Please note that this yet does not work if you cross compile from a different
architecture.
Previously, it could happen that regular symbols referenced
only as part of a template instance (e.g. a lambda passed as
an alias parameter) were not even emitted in the wrong module,
but not at all because mustDefineSymbol would return false to
them when being analyzed during codegen of the wrong module.
This issue might affect incremental compilation with DMD as
well, and the fix should be discussed with the upstream devs.
GitHub: Fixes#249.
