By letting LLVM narrow compile-time real_t values to float/double IR
constants. We previously relied on the host, which turns signalling
real_t NaNs to quiet float/double NaNs.
Signalling NaNs are characterized by their most-significant mantissa bit
being 0 (and at least for D the 2nd-most-significant mantissa bit being
set to distinguish them from infinity). The host truncation led to the MSB
getting set while keeping the rest of the mantissa (i.e., both MSBs set).
Here's the resulting bitpattern table in hex:
float: double: x87 real:
init old: 7fe00000 7ffc000000000000 7fffa000000000000000
init new: 7fa00000 7ff4000000000000 7fffa000000000000000
qnan: 7fc00000 7ff8000000000000 7fffc000000000000000
DMD 2.074.0 produces wrongly quiet float/double init values.
A Win32 LDC build (with double-precision real_t) still loses the
signalling-ness for {float,double,64-bit real}.init, probably due to the
FPU being used instead of SSE.
* [NFC] Make LDC somewhat aware of addrspaces.
Required so that we don't generate invalid code when dealing with pointer to addrspaces other than zero.
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 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.
Previously, the transitory state only needed and valid during
generation of the LLVM IR for the function body was conflated
with the general codegen metadata for the function declaration
in IrFunction.
There is further potential for cleanup regarding the use of
gIR->func() and so on all over the code base, but this is out
of scope of this commit, which is only concerned with those
IrFunction members moved to FuncGenState.
GitHub: Fixes#1661.
That's apparently what DMD does and what currently happens for all
non-MSVC targets anyway.
For MSVC, we need this to enforce the `any` selection instead of
`no duplicates`, otherwise the linker complains about multiply defined
symbols and refuses to link without an extra command line option
(which in turn outputs a non-suppressable warning).
Add LLVM zeroext attribute to char and wchar types so they are
compatible with similar sized C ABI unsigned int types.
In particular, this is needed for ARM (fixes runnable/cppa.d at -O3)
and seems like proper behavior for all supported ABIs even though the
x86 ABIs get by without this.
Note that we don't set t->ctype (we'd need a new IrTypeEnum or something
along the lines). This is okay because we don't do so for enums in either
case, even in the normal code paths. Enums are regarded as being
"transparent" in that sense. We might want to rethink this in the future,
though.
Fixes DMD test case 'ice13792'.
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
