Since the progress bar results in large output that is broken due to the use of
ncurses and we already use the flag that gives verbose output on test failures,
let's just disable the progress bar.
lit (LLVM Integrated Tester) [0] by default uses as many threads as the build host
has cores, ignoring the user's core settings for the build.
This passes the configured core count on to lit, along with LLVM's default
settings for it which we otherwise override in the process [1].
[0]: https://www.llvm.org/docs/CommandGuide/lit.html
[1]: 329fda39c5/llvm/CMakeLists.txt (L559-L565)
The missing xcrun meant builtins were missing from darwin. This
apparently wasn't an issue until now, but is in projects using
`@available` checks. (The ARM64 hack was apparently the previous
solution to fixing broken SDK detection.)
The new LLVM commit is just before the LLVM 15 fork off.
The readme describing upgrade process so it is easier for others to do.
Co-Authored-By: Dylan Green <Dylan.Green@Obsidian.Systems>
Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>
This is the supported way rocm is tested.
It makes packaging in nix a *lot* easier (see the code size).
An important change is the dontLink detection in the clang/clang++
wrapper script: When compiling with --cuda-device-only,
the linker must not be set, otherwise e.g. the blender kernels fail to
compile.
It is possible to both be bare metal and have a libc (newlib).
This libc doesn't provide very much --- not enough for CMake to think
the C toolchain works. We therefore adjust our logic so we hit the "bare
metal" case with or without libc.
The "use LLVM" bootstrap is intentionally not affected.
GCC 10 sets -fno-common by default. This broke some packages, so
when moving to GCC 10 we initially disabled this behavior. This
commit reverts that, bringing us closer to the standard and
upstream.
Co-authored-by: Sergei Trofimovich <slyich@gmail.com>
Reverts #162607 / 1748887ff2.
Reason for revert: This change caused llvm-config{,-native} to be unable
to find static archives bundled with LLVM, as has been [reported]. Ever
since #152944 using moveToOutput in LLVM is _evil_ because llvm-config
obtains it knowledge about the installation locations from the CMake
configure step.
Consequently a change like #162607 will need to be implemented by making
LLVM itself install the static archives to the correct location or by
adding yet another patch which updates llvm-config's knowledge of the
location. The latter is not desireable in my opinion, though, since it
is just asking for this sort of trouble: Before #152944 we had an
outputs.patch that did this sort of things which broke spectacularly in
edge cases.
Fixes#148117.
[reported]: https://github.com/NixOS/nixpkgs/issues/148117#issuecomment-1158245576
