These helpers are statically linked into each DLL/EXE that uses
them.
They are primarily used for atomic access to variables that are
larger than what the platform natively can support - i.e. primarily
for accessing atomic variables larger than 8 bytes.
The fallback implementations rely on explicit locks (spinlocks
in practice).
As the locks are statically linked into each module that uses the
atomic variable, any concurrent access to such an atomic variable
from two different DLLs/EXEs wouldn't actually end up being
properly atomic.
However cross-module atomic variables (larger than 8 bytes) is
very rare so this isn't deemed to be much of a practical issue.
In GCC based toolchains, the corresponding helpers reside in
a separate shared library, libatomic-1.dll (although it can also
be linked statically).
Don't assume that any host argument indicates cross compiling for
Windows.
Update build-all to pass --host arguments to strip-llvm as well,
for consistency.
This makes the built toolchain usable outside of MSYS2 too.
For running tests, this has another very subtle effect.
If the toolchain is built in the MSYS2 clang64 environment, the
compiler binary depends on libc++.dll. This DLL is found in $PATH,
in /clang64/bin.
When building/running tests, the current working directory will be
e.g. llvm-mingw/test/x86_64. At some point while building/running
tests, the test makefile will copy the llvm-mingw toolchain's
runtime DLLs into this directory in order to be able to execute those
newly built binaries. This also includes another, different libc++.dll.
When a libc++.dll exists in the current directory, this is preferred
over the one found further back in $PATH in /clang64/bin. As this
file is copied in parallel with other build jobs that might be
doing compilation, those compilation processes may end up loading
this other DLL. If fully copied it probably shouldn't be an issue,
but if not fully copied yet, who knows what might happen.
By making sure that there is a libc++.dll in the same directory as
the toolchain executables (rather than expecting it to be found
further back in $PATH), we ensure that this DLL is loaded and used
instead of the one in the current directory.
This should fix stray errors when running tests in the clang64
environment.
This version fixes a race condition in the build, which in most
cases was benign but in rare cases could successfully build a Python
that would crash at runtime.
This skips test that use a lot of memory. In particular, there's
one test that would use up to 6.8 GB of memory, while the GitHub
Actions runners only have 8 GB of memory available.
This parameter was added in 122064a6303eb9c06e0af231f5a4ce145d9a2e67
in the llvm-project main branch, and backported to 17.x in
aa03fba83b17bbfcd9ed869efed2818b503875d6.
This allows seeing the names of tests as they are executed, making
the intermediate log output on github actions more useful. It
also makes it easier to correlate test issues between tests as
they are executed (e.g. if one test causes another one to run out
of memory).
Also run with --time-tests, allowing identifying slow tests.
This was already applied in the separate libcxx test job added in
7483eae1821766a0f84dbd96f5619058f7065008; this backports the change
into the test job in the main build file.
This version fixes the following issues for mingw/windows targets:
- Fix linking the lli tool if built with asan enabled
- Fix compiling for the aarch64 target if specifying -mtune=cortex-a53
- Fix initialization order among constructors within one translation unit
This contains a few bugfixes for mingw use cases:
- LLD in 17.0.1 and the earlier 17.x release candidates looked up
libraries (including libraries named as a relative path) preferring
to search in toolchain relative paths over first testing from the
current directory. In some cases, this could cause cryptic build
failures; see https://github.com/llvm/llvm-project/issues/67779.
- Options that only are relevant for linking, like -mwindows, used
to be accepted (but produce a warning) if used in a compilation-only
job. In the earlier 17.x releases/RCs, such warnings caused an
error instead; see https://github.com/llvm/llvm-project/issues/64464
and https://github.com/mstorsjo/llvm-mingw/issues/371.
This only provides the main binary llvm-cxxfilt; it doesn't
provide the binutils-style frontends named [<triple>-]c++filt.
If we were to provide such frontends, we'd need to make them
default to --strip-underscore for i686 triple prefixes, and
for the prefixless case when the default architecture is i686.
This allows simplification, this functionality was added long
ago to CMake.
Further motivation is to be able to re-direct the installation,
make/ninja install allow this by setting DESTDIR but this
generally doesnt work well with window paths (see [1]).
[1] - https://cmake.org/cmake/help/latest/envvar/DESTDIR.html#envvar:DESTDIR
Ninja isn't documented as one of the tools provided by the CI runner
images, but it used to be available implicitly installed before
in the windows-2022 images. Since the 20230918.1.0 image update,
it no longer is available out of the box; see
https://github.com/actions/runner-images/issues/8343.
There was a minor issue with the version information in what
was tagged as 17.0.0, so 17.0.1 is the first proper stable
release on the 17.x release branch.
This brings in a rather large update of the D3D12 header
(d3d12.idl/d3d12.h), which should now be mostly complete and up
to date with the current versions from Microsoft.
Martin Storsjö