Update LLVM to 15.0.4

[xavier2k6]

https://github.com/llvm/llvm-project/releases/latest

[XVilka]

The relevant Windows changes are:

Windows Support

• Add support for MSVC-compatible /JMC//JMC- flag in clang-cl (supports X86/X64/ARM/ARM64). /JMC could only be used when /Zi or /Z7 is turned on. With this addition, clang-cl can be used in Visual Studio for the JustMyCode feature. Note, you may need to manually add /JMC as additional compile options in the Visual Studio since it currently assumes clang-cl does not support /JMC.
• Implemented generation of SEH unwind information on ARM. (C++ exception handling in MSVC mode is still unimplemented though.)
• Switched MinGW mode on ARM to use SEH instead of DWARF for unwind information.

[alabuzhev]

Please consider updating LLVM in the VS2022 image:

• Currently installed version is 14.0.6:

  "C:\Program Files\LLVM\bin\clang.exe" --version
  clang version 14.0.6
  Target: x86_64-pc-windows-msvc
  Thread model: posix
  InstalledDir: C:\Program Files\LLVM\bin

• Currently installed Visual Studio 2022 is already incompatible with it, so clang-cl builds are broken:

  In file included from C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\algorithm:9:
  C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\yvals_core.h(807,1): error: static_assert failed "Error in C++ Standard Library usage."
  _EMIT_STL_ERROR(STL1000, "Unexpected compiler version, expected Clang 15.0.0 or newer.");
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\include\yvals_core.h(462,5): note: expanded from macro '_EMIT_STL_ERROR'
  static_assert(false, "Error in C++ Standard Library usage.")
  ^             ~~~~~
  1 error generated.

[XVilka]

Makes sense to go straight to LLVM 16.0 now:

• For MinGW, generate embedded -exclude-symbols: directives for symbols with hidden visibility, omitting them from automatic export of all symbols. This roughly makes hidden visibility work like it does for other object file formats.

• When using multi-threaded LLVM tools (such as LLD) on a Windows host with a large number of processors or CPU sockets, previously the LLVM ThreadPool would span out threads to use all processors. Starting with Windows Server 2022 and Windows 11, the behavior has changed, the OS now spans out threads automatically to all processors. This also fixes an affinity mask issue. (D138747)

• When building LLVM and related tools for Windows with Clang in MinGW mode, hidden symbol visiblity is now used to reduce the number of exports in builds with dylibs (LLVM_BUILD_LLVM_DYLIB or LLVM_LINK_LLVM_DYLIB), making such builds more manageable without running into the limit of number of exported symbols.

• AArch64 SEH unwind info generation bugs have been fixed; there were minor cases of mismatches between the generated unwind info and actual prologues/epilogues earlier in some cases.

• AArch64 SEH unwind info is now generated correctly for the AArch64 security features BTI (Branch Target Identification) and PAC (Pointer Authentication Code). In particular, using PAC with older versions of LLVM would generate code that would fail to unwind at runtime, if the host actually would use the pointer authentication feature.

• Fixed stack alignment on Windows on AArch64, for stack frames with a large enough allocation that requires stack probing.

• For the MinGW driver, added the options -mguard=none, -mguard=cf and -mguard=cf-nochecks (equivalent to /guard:cf-, /guard:cf and /guard:cf,nochecks in clang-cl) for enabling Control Flow Guard checks and generation of address-taken function table.

• Switched from SHA1 to BLAKE3 for PDB type hashing / -gcodeview-ghash

• Fixed code generation with emulated TLS, when the emulated TLS is enabled by default (with downstream patches; no upstream configurations default to this configuration, but some mingw downstreams change the default in this way).

• Improved detection of MinGW cross sysroots for finding sysroots provided by Linux distributions such as Fedora. Also improved such setups by avoiding to include /usr/include among the include paths when cross compiling with a cross sysroot based in /usr.

• Fix incorrect alignment attribute on the this parameter of certain non-complete destructors when using the Microsoft ABI. Issue 60465.

• When compiling for Windows in MSVC compatibility mode (for example by using clang-cl), the compiler will now propagate dllimport/export declspecs in explicit specializations of class template member functions (#54717):

  template <typename> struct __declspec(dllexport) S {
  void f();
  };
  template<> void S<int>::f() {}  // clang-cl will now dllexport this.

  This matches what MSVC does, so it improves compatibility, but it can also cause errors for code which clang-cl would previously accept, for example:

  template <typename> struct __declspec(dllexport) S {
  void f();
  };
  template<> void S<int>::f() = delete;  // Error: cannot delete dllexport function.
  template <typename> struct __declspec(dllimport) S {
  void f();
  };
  template<> void S<int>::f() {};  // Error: cannot define dllimport function.

  These errors also match MSVC’s behavior.

• Clang now diagnoses indirection of void * in C++ mode as a warning which defaults to an error. This is compatible with ISO C++, GCC, ICC, and MSVC. This is also now a SFINAE error so constraint checking and SFINAE checking can be compatible with other compilers. It is expected that this will be upgraded to an error-only diagnostic in the next Clang release.

  void func(void *p) {
  *p; // Now diagnosed as a warning-as-error.
  }

  Clang now diagnoses use of a bit-field as an instruction operand in Microsoft style inline asm blocks as an error. Previously, a bit-field operand yielded the address of the allocation unit the bit-field was stored within; reads or writes therefore had the potential to read or write nearby bit-fields. (#57791)

  typedef struct S {
  unsigned bf:1;
  } S;
  void f(S s) {
  __asm {
  mov eax, s.bf // Now diagnosed as an error.
  mov s.bf, eax // Now diagnosed as an error.
  }
  }

  See:

• https://releases.llvm.org/16.0.0/docs/ReleaseNotes.html#changes-to-the-windows-target

• https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html

[XVilka]

Looks upgraded on VS2019 image:

C compiler for the host machine: clang-cl (clang-cl 16.0.1)
C linker for the host machine: lld-link lld-link 16.0.1

[xavier2k6]

LLVM 18.1.1 seems to be on latest VS2019/2022 images.