As *the* way to access the IrType associated with a Type via its `ctype`
field. Most importantly, it makes sure all access is redirected to the
*unqualified* type's `ctype`, which allows to get rid of the 'multiple
types' workaround for aggregates in DtoType(). Those were e.g. hit for
`shared struct SpinLock`, where the struct's type includes the `shared`
modifier...
Reducing some ugliness found while investigating
https://issues.dlang.org/show_bug.cgi?id=19762.
A struct or class can apparently have 'semantic errors', in which case
the associated type is Terror. In DtoType(), we've been associating
Terror with the IrType (via `ctype`) for the first such aggregate, so
the LL type was *some* struct and got reused for other erroneous
aggregates with Terror type.
Use an opaque '_error_' LL struct in these cases now, and don't
associate Terror with any IrType anymore.
Fixes#3490 by avoiding unnecessary extra key allocations for the literals cache etc.
Also gets rid of code duplication and improves IRState encapsulation.
This is exactly what happened for the 4 problematic delegate literals
for the Phobos unittests - DtoDefineFunction(fd) could result in that
definition ending up as available_externally - all done as part of
DtoResolveFunction(), which declared it, and DtoDeclareFunction()
defined it as available_externally, and the outer DtoDefineFunction()
returned early in that case without fixing up the linkage.
Emulation for @weak global variables is still left out but should be
analogous.
The test adaptations are mostly a revert of 3893840f. The testcase has
shown that @weak hasn't worked properly for ELF (linker apparently
prefers the version in the 1st object file, independent of whether it's
weak or not), because the functions are emitted in COMDATs.
clang emits COMDATs for templates and inline functions only, not for
regular functions.
Not all type declarations yet (e.g., some TypeInfo subtypes are still
accessed directly), but those already wrapped as LazyType in the
gen/runtime.cpp module (with check and proper error msg in case object.d
doesn't contain a required declaration).
The dtors can be checked at compile-time; insert a runtime check for the
monitor before finalizing the stack-allocated class object via druntime
call.
See issue #2515.
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).
