| Age | Commit message (Collapse) | Author | Lines |
|---|
|
when compiling target LLVM with `opt-dist local` on Windows/MinGW,
profraw files are being compressed with zlib, so compiling without it
will make `llvm-profdata` complain about lacking of zlib support. this
error is shown:
`profile uses zlib compression but the profile reader was built without
zlib support`
example from llvm test suite: https://github.com/llvm/llvm-project/blob/76b5fcbf975547251faaeed8b567ea09d139a607/llvm/test/tools/llvm-profdata/nocompress.test#L15
|
|
This PR makes a fairly large version update to CMake and cc, so it is
likely that LLVM is built differently.
|
|
Add target and compile the amdgpu llvm backend.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
Set LLVM_ENABLE_ZSTD alongside LLVM_ENABLE_ZLIB so that --compress-debug-sections=zstd is an option.
Use static linking to avoid a new runtime dependency. Add an llvm.libzstd bootstrap option for LLVM
with zstd. Set it off by default except for the dist builder. Handle llvm-config --system-libs output
that contains static libraries.
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/753
|
|
|
|
Adds initial support for DataFlowSanitizer to the Rust compiler. It
currently supports `-Zsanitizer-dataflow-abilist`. Additional options
for it can be passed to LLVM command line argument processor via LLVM
arguments using `llvm-args` codegen option (e.g.,
`-Cllvm-args=-dfsan-combine-pointer-labels-on-load=false`).
|
|
Three tasks have been implemented here.
Add a new `download-ci-llvm = if-unchange` option and enable if by
default for `profile = codegen`.
Include all build artifacts by traversing the llvm-project build output,
Keep the downloadable llvm the same state as if you have just run a full
source build.
After selecting the codegen profile during ./x.py setup, the submodule
will be automatically downloaded.
|
|
CMAKE_SYSTEM_NAME is defined on a cross build if the target is
recognized. Without this explicit definition cmake will assume that
we're building for the host platform which can bring in unwanted
compiler and linker flags.
Also, add a warning on cross builds with unknown target to aid in
cross builds for future platforms.
|
|
|
|
This was missed in https://github.com/rust-lang/rust/pull/96971 and
resulted in the LLVM we cache in CI being different from the one built
locally. We didn't catch it because nothing tested the loong support.
|
|
This option was added to LLVM in
https://reviews.llvm.org/D121750?id=416339. It makes `llvm_unreachable`
in builds without assertions compile to an `LLVM_BUILTIN_TRAP` instead
of `LLVM_BUILTIN_UNREACHABLE` (which causes undefined behavior and is
equivalent to `std::hint::unreachable_unchecked`).
Having compiler bugs triggering undefined behavior generally seems
undesirable and inconsistent with Rust's goals. There is a check in
`src/tools/tidy/src/style.rs` to reject code using `llvm_unreachable`.
But it is used a lot within LLVM itself.
For instance, this changes a failure I get compiling `libcore` for m68k
from a `SIGSEGV` to `SIGILL`, which seems better though it still doesn't
provide a useful message without switching to an LLVM build with asserts.
It may be best not to do this if it noticeably degrades compiler
performance, but worthwhile if it doesn't do so in any significant way. I
haven't looked into what benchmarks there are for Rustc. That should be
considered before merging.
|
|
|
|
|
|
The LLVM disassembler is needed for the test introduced in
https://github.com/rust-lang/rust/pull/97550.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
We started using it in https://github.com/rust-lang/rust/pull/94023.
|
|
This will make 'lld' available locally now, instead of
needing to wait for the next LLVM submodule bump.
|
|
This will ensure the optimized LLVM is used for local builds after rebasing
immediately, rather than needing to wait for a future LLVM bump.
|
|
- Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked
statically
- Add `link-type.txt` so bootstrap knows whether llvm was linked
statically or dynamically
- Don't assume CI LLVM is linked dynamically in `bootstrap::config`
- Fall back to dynamic linking if `link-type.txt` doesn't exist
- Fix existing bug that split the output of `llvm-config` on lines, not spaces
- Enable building LLVM tests
This works around the following llvm bug:
```
llvm-config: error: component libraries and shared library
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a
thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles"
```
I'm not sure why llvm-config thinks these are required, but to avoid
the error, this builds them anyway.
- Temporarily set windows as the try builder. This should be reverted
before merging.
- Bump version of `download-ci-llvm-stamp`
`src/llvm-project` hasn't changed, but the generated tarball has.
- Only special case MacOS when dynamic linking. Static linking works fine.
- Store `link-type.txt` to the top-level of the tarball
This allows writing the link type unconditionally. Previously, bootstrap
had to keep track of whether the file IO *would* succeed (it would fail
if `lib/` didn't exist), which was prone to bugs.
- Make `link-type.txt` required
Anyone downloading this from CI should be using a version of bootstrap
that matches the version of the uploaded artifacts. So a missing
link-type indicates a bug in x.py.
|
|
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated
ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This commit
updates the ci-llvm stamp to resolve that problem.
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
