That's just begging for trouble with -lowmem, as they contain roots to
(potentially GC-managed) D arrays.
After a rather superficial grep-check for `new ` in the *.{cpp,h} files,
these should be about all occurrences of frontend stuff previously
allocated on the C++ heap.
I.e., the ABI-specific decision for which parameter types to prefer
passing a ref over a value.
The x86_64 and AArch64 ABIs are pretty clear - use a ref if the POD type
cannot be passed in registers. For all others, use a simple default
heuristic based on the type size - if larger than 2 machine words, use a
ref. Note that this includes x87 `real` for the 32-bit x86 ABI.
The only observable effect for now is that non-Apple AArch64
TypeInfo_Struct emissions might contain a populated m_arg1, which is
a prerequisite for TypeInfo-based core.vararg.va_arg().
This reduces the overhead for auto-detecting and setting up an MSVC
toolchain from a very rough 1 second to about 8 milliseconds on my box.
Enabling the auto-detection by default (and so preferring MSVC over the
'internal' toolchain if there's a Visual C++ installation) is now
possible, fixing issues like #3402.
The MSVC setup now consists of the bare minimum - prepending 3
directories to the LIB env var and 1-2 directories to PATH.
Instead, error out whenever requested by an expression-less
`synchronized` statement, including source LoC to track it down.
This is safer, especially since the previous initial warning may likely
be suppressed, and makes this host-agnostic.
Also suppress previous warnings about unknown `` and `none` OS, treating
these like `unknown`.
Bail out on unsupported vector ops (not checking the rhs type for binops
though) in the frontend instead of causing LLVM errors.
Also precompute the target's critical section size once at startup, like
DMD.
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
