Extend the aarch64-w64-mingw32 prefix to provide ARM64EC libraries
alongside standard AArch64 libraries, replacing the separate
arm64ec-w64-mingw32 prefix. This aligns with how MSVC distributes
ARM64EC libraries and enables the linker to process both targets
simultaneously into a single hybrid binary.
This extensively utilizes LLVM's -marm64x option, compiling both
targets in a single compiler invocation to produce hybrid object
files (unlike MSVC tools, which require separate compilation passes).
When building throwcatch-main.exe, we link with "-L.". Since we
copy in the runtime libraries for executing tests, we might have
libc++.dll present if we aim for the target "test" while
compiling.
For arm64x builds, we could end up trying to link directly against
the arm64x libc++.dll rather than with the import library. Linking
directly against an arm64x DLL doesn't work yet in 23.1.0-rc1, so
avoid hitting this situation for now.
This is a temporary workaround; linking against an arm64x DLL should
work too, and the fix is being backported to the next RC.
Some notable changes since 22.x:
- Linking a weak declaration against a weak definition now works
properly
- Many improvements for ARM64EC, including supporting linking
against ARM64EC thin libraries
- Support for compiling for ARM64X (files targeting both native
aarch64 and ARM64EC) with the -marm64x flag, which generates
a multi-architecture object file. This should make it much
more feasible, build system wise, to actually build things for
ARM64X.
- Fixed aarch64 branch protection on Windows to use the right
signing key (previously it the wrong one, which was inactive on
Windows, and which broke unwinding in older versions of Wine)
Previously, we added the llvm-mingw bundled python to the head
of PATH, but we didn't expect to use it after all.
(In other tests, where we explicitly want to use the llvm-mingw
bundled python, we set -DPython3_EXECUTABLE="$Env:PYTHON_EXE.)
Previously (with runner image version 20260622.87.1), CMake ended
up choosing
C:/hostedtoolcache/windows/Python/3.13.14/x64/python3.exe, but
now (with runner image version 20260629.93.2) we ended up picking
C:/llvm-mingw/python/bin/python3.14.exe instead.
With the newer runner images, we do have
C:\hostedtoolcache\windows\Python\3.13.14\arm64\python3.exe in
PATH, but it is unclear why that doesn't get picked.
(Picking another version than the first one in PATH would make
sense if we'd have Python_FIND_STRATEGY=VERSION set. According to
the docs, that shouldn't be the default any longer though, and it
wouldn't explain why it picked 3.13 before when we provide
3.14.)
In any case, just skip adding our version to PATH since we
don't intend to use it, to make it use the system provided
version.
This is the newest version currently available in the Ubuntu 24.04
repos.
This fixes building; previously it failed to build libc++, which only
supports being built with one of the two preceding versions of Clang.
This reverts commit 1d8c107d49.
After 49e14021be, when using F(-NAN)
instead of -F(NAN) to hide the negation, this test passes correctly.
I hadn't realized that GCC and Clang optimized cos(-x) = cos(x), when
I made 1d8c107d49 (and at the time, the
F() macro didn't work properly with -NAN on all toolchains).
In the former form, the negation of NAN is hidden inside the
optimization blocking macro/wrapper. After
9be66e9d22, F(-NAN) works just as
well as -F(NAN).
This avoids test issues with recent optimizations in LLVM.
https://github.com/llvm/llvm-project/pull/193586 seems to make
the compiler consider known symmetry for hyperbolic math functions,
exploiting the fact that cosh(-x) is equal to cosh(x) (for values
other than NANs). By hiding the negation inside the F() wrapper,
the compiler can't reason about is existence.
checkout@v5 should be the same as checkout@v4, just running on
Node 24. checkout@v6 has got a few other minor changes that
shouldn't make any difference; opt in to newer behaviours now.
This fixes importing the _ctypes module, if a shared libffi doesn't
happen to exist on the host system with the right so version.
Since Python 3.12, such a build error ends up failing the build,
while it previously passed silently even if some parts of the build
had failed.
This makes sure the openmp tests actually are executed; since
switching to the runtimes build of openmp for the tests (in
98684ab807), the tests weren't
executed, as it no longer found the tools necessary for executing
the tests - as they are expected to be specified differently
in the runtimes build mode.
This requires the commit 48a5119d8e7d7236a28c14d06ec215ef3366ef90
(backported to 22.x in 9794a7932465bdc244b327388905d66df38485e2,
part of the 22.1.1 release) in llvm-project, to be able to run
tests without actually building clang in the same build as the
test tools.
Since 6295b8e763503644961f9087382f80965b98d466 in llvm-project,
one no longer can configure the openmp project entirely standalone,
one has to do it through the runtimes directory.
However, in practice, this currently leads to no tests being
executed at all, as the runtimes build setup doesn't support
pointing to an external FileCheck executable - it currently has
to be part of a full bootstrapping build.
Since 6295b8e763503644961f9087382f80965b98d466 in llvm-project,
it's no longer possible to build openmp entirely standalone;
now one has to build it through the runtimes directory.
Jacek Caban