[clang] implement CWG2064: ignore value dependence for decltype
The 'decltype' for a value-dependent (but non-type-dependent) should be known,
so this patch makes them non-opaque instead.
This patch also implements what's neceessary to allow overloading
on pure differences in instantiation dependence, making `std::void_t`
usable for SFINAE purposes.
This also readds a few test cases from da98651, which was a previous attempt
at resolving CWG2064.
Fixes #8740
Fixes #61818
Fixes #190388
[clang] Add arm64_neon.h wrapper on windows (#196014)
Add an MSVC-compatible <arm64_neon.h> resource header that forwards to
Clang's generated <arm_neon.h>. This lets ARM64 Windows code using the
MSVC header name lower NEON intrinsics through Clang builtins instead of
eaving external neon_* calls such as neon_ld1m4_q32
Fixes #195683
[ADT] Avoid map storage for small SmallMapVector (#196473)
SmallMapVector previously used SmallDenseMap for its index, which still
initializes and maintains map storage even when the number of entries is
tiny.
Teach MapVector to support a vector-only small mode. While the entry
count stays
within the configured small size, operations use the underlying vector
directly.
When the size grows past the threshold, the map index is built and
subsequent
operations use the regular MapVector path.
This mirrors the small-size strategy used by SmallSetVector.
Fix a longstanding bug on 64 bit ports with ABIs requiring sign-extension when returning 32-bit values in registers. Alpha, MIPS N64, RISCV.
With these ABIs it is necessary for the syscall return code to manually
sign-extend all 32-bit return values. If we don't, everything may look
just fine, until a syscall return value is spilled to the stack and then
reloaded. At that point, the zero-extended form produced by C assignment
into the 64-bit register for return to userspace will be sign-extended
upon reload, producing a different, corrupt value which will fail comparisons.
This was observed with a getuid() != geteuid() deep inside sshd on N64, on an
unusual system that had some very large UIDs with bit 31 set - but is quite
difficult to reproduce with small tests, since register pressure and compiler
behavior determine whether the conditions necessary to trigger the bug will
exist.
The easiest way to see whether a new target needs this treatment is to
look at its GCC configuratrion; if its PROMOTE_MODE has UNSIGNEDP = 0
for SImode, the sign-extension in syscall() is necessary.
