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
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.
