Make the existing 64-bit code in argtypes.d DMD-specific (required due
to codegen issues) and add a new separate implementation for the SysV
x86_64 ABI to be used by LDC/GDC, closely following the algorithm laid
out in the spec [1].
Also don't needlessly compute a struct's argtypes for Win64 and
non-x86[_64] targets.
This fixes LDC ABI issues wrt. C[++] compatibility on Posix x86_64,
e.g., https://issues.dlang.org/show_bug.cgi?id=13957.
I went with signed integers to represent GP registers, and float/double/
__vector(double[N]) for vector registers (SSE + AVX); integer signedness
and vector element type are arbitrary.
[1] https://www.uclibc.org/docs/psABI-x86_64.pdf
Primarily not to break size_t interop. A size_t is probably much more
frequently used than `(unsigned) long long` (which Apple sadly chose for
their C++ `(u)int64_t`).
Which is a serious problem if the host real_t is a double and the target
`real` features a higher precision (cross-compilation).
`Target::RealProperties` are set up for the target's `real`, so
max/min_normal/epsilon may over/underflow, and so would
`DoubleProperties` if aliased.
By using upstream's Target.prefixName(), which prepends an additional
underscore on OSX/Darwin for C++ symbols.
We then need to prevent LLVM from implicitly prepending a third one.
As 'processing' a signalling NaN may convert it to a quiet NaN. Apparently
happening on 32-bit x86 using the x87 FPU, but not on x86_64 with SSE.
This fixes potential issues with different constants being used when
mixing natively and cross-compiled objects/libs and failing bitwise `is`
comparisons etc.
See https://forum.dlang.org/post/nsp1ql$ivu$1@digitalmars.com for Martin
Nowak's summarized findings.
While parsing of floating-point literals and CTFE still operate with the
host LDC's real type, compile-time reals can in principle be emitted in
arbitrary precision via LLVM software conversion, therefore paving the way
for cross-compilation to all targets.
The representable constants are still limited by the compile-time real_t
precision. E.g., LDC on Windows with its 64-bit reals can't hold and emit
an 80-bit `real.max` when cross-compiling to a non-Windows x86(_64)
target; the compile-time value will silently overflow to infinity and
later be emitted as 80-bit infinity.
LDC on AArch64 with its 128-bit quad-precision reals on the other hand can
hold and emit reals for all targets, making it a universal cross-compiler
with quad-precision compile-time reals in hardware.
We don't use the strange 2x64-bit PPC double-double format (see
`getRealType()` in `ir/irtype.cpp`), but would more or less support it
(the type properties (max, min_normal...) still need to be determined;
LLVM isn't sure about those either...).
The part needing most attention was ddmd.root.ctfloat, ddmd.target (incl.
gen/target.cpp) and ddmd.builtin. The front-end is now prepared for
elaborate compile-time floating-point types to allow for proper cross-
compilation.
This version still uses the host's `real` type for compile-time reals,
except for MSVC hosts, which still use 64-bit doubles (when compiled with
DMD host compiler too).
Some other changes:
* semantic*() of Statements extracted from statement.d to statementsem.d
* mangle() -> mangleToBuffer()
* Identifier::string -> toChars()
* Token::float80value => floatvalue
* Dsymbol::isAggregateMember() => isMember()
* BoolExp is no more
* ddmd.root.ctfloat: LDC-specific CTFE builtins
The missing alignment is a front-end bug; this is a combined backport
of dlang/dmd@b9aa6ed and dlang/dmd@a93fa3c.
For POSIX targets, the critical section size was assumed to be identical
to the host compiler's, which generally isn't true when cross-compiling.
DtoMutexType() wasn't used anywhere, so I removed it.
Notably, the glue layer side of the changed multiple interface
inheritance layout (DMD a54e89d) has not been implemented yet.
This corresponds to DMD commit 3f6a763c0589dd03c1c206eafd434b593702564e.
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
Trying to get the alignment right by using the first non-default one
in the following order of descending priority:
VarDeclaration::alignment [variables only of course]
Type::alignment()
Type::alignsize()
This fixes `align(x) struct S { ... }`.
