Conversation
|
How neat is it that upgrades are as simple as this now! |
|
@bors try @rust-timer queue
It's quiet. Too quiet... |
This comment has been minimized.
This comment has been minimized.
|
⌛ Trying commit 776fb8e470bab3324cc0d9e34ab6a905f774f19e with merge e6dbb34783cfa1de81bc2fffcbb8bbe0a5a4f9fa... |
|
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Ha, I did say it was too quiet! This is kind of weird though, because I tested dist-x86_64-linux locally, though I was using the DEPLOY_ALT=1 configuration. Either this only happens with DEPLOY=1, or something managed to break in the one day in between. |
|
The backtrace for the crash looks like this: I haven't been able to reproduce this outside of rustc yet. Edit: With symbols: |
|
Note that it did complete one build, but breaks in further PGO. On my machine, it crashed while "Building stage1 library artifacts" in this command: Lines 194 to 198 in d7948c8 I don't see a detailed crash in the CI log, but it seems to have gotten just past that and failed in the next collector. |
|
For me and in CI the crash is during the third profile collection, using the build that has been PGO optimized and has BOLT instrumentation. Probably a thing to try would be to drop the BOLT part and see whether that works. If not, then this is probably a PGO miscompile. Doesn't sound fun to debug, might be easiest to bisect. |
I am really, really sorry for raising that 🏴 😿 |
|
Hrm, I can reproduce a crash even on llvm/llvm-project@3c0c24e, which I had previously successfully tested in #105956. |
|
Dropping |
|
BOLT isn't always super stable, so it might very well be caused by it. We use BOLT |
|
I tried a local build with 15.0.7 in |
|
Using 16.0.0-rc2 as the host compiler fails with: Presumably due to https://reviews.llvm.org/D135402. |
|
Related: #105967 |
|
@TimNN Yeah, that's the same problem. @chbaker0 Unfortunately, the patch from #108017 doesn't seem to actually fix the issue for this case. Possibly this is due to the issue mentioned by @bjorn3 in #105967 (comment)? I dumped the rustc invocation, and it looks like this:
Notably, we're building both a dylib and rlib, and the |
|
⌛ Testing commit b238a76 with merge 1f133b9f1ef79a6aca894d54699d0906b944c330... |
|
💔 Test failed - checks-actions |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
⌛ Testing commit b238a76 with merge 8cead7cc4c89c4cac88bb3ab9a9f2b57be9f9aa7... |
|
💔 Test failed - checks-actions |
|
☀️ Test successful - checks-actions |
|
Congratulations! Though I'm wondering if the recently introduced bootstrap rustc segfaults in CI like this one are related to new LLVM? It has happened in all 4 attempted merges since this one was merged. |
|
Finished benchmarking commit (4a04d08): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
|
Interestingly I can bootstrap rustc-1.68.0 using system LLVM 16.0.0 and even get 0 test failures on x86_64-linux-gnu. Maybe something has changed since 1.68.0, or maybe I'm not using some aggressive optimizations (the "BOLT" thing for example). |
|
This caused several failures in stdarch CI: rust-lang/stdarch#1394 wasm32-wasi (cc @alexcrichton): x86_64-unknown-linux-gnu: |
|
The CI crashes are pretty weird. The rustc produced by dist-x86_64-linux seems to work just fine by itself. But a new stage1 rustc build linked against its libLLVM.so crashes. Not sure what that means yet. |
|
Does a |
|
@the8472 Could be. My first suspicion would be an ABI mismatch. dist-x86_64-linux builds with clang, while most other builders use gcc. And createTargetMachine() was switched to use |
Thanks for the cc! Let's continue that thread of discussion in rust-lang/stdarch#1396 (nothing amiss with LLVM 16 itself, just backend changes as expected) |
|
This is the ABI incompatibility I suspect: https://clang.godbolt.org/z/qbW5a58qv dist-x86_64-linux uses libstdc++ 7.5, which has different std::optional ABI from future versions. So if other builders use a newer GCC version, they end up being incompatible with the built libLLVM.so. Not sure what to do about this. The right way to fix this would probably be to also distribute llvm-wrapper, so that we only link against a C API. But this is probably not a short term solution (I believe llvm-wrapper is currently statically linked in.) Possibly we could get away with updating the builder to GCC 8, assuming other builders using these artifacts are also on GCC 8 or newer. |
|
That ABI difference is also visible with direct GCC: https://godbolt.org/z/KvPx7En9f, and
I think that's the way to go. AFAICS all the test builders are on at least |
|
Visiting for rustc-perf triage
@rustbot label: +perf-regression-triaged |
This updates Rust to LLVM 16. It also updates our host compiler for dist-x86_64-linux to LLVM 16. The reason for that is that Bolt from LLVM 15 is not capable of compiling LLVM 16 (llvm/llvm-project#61114).
LLVM 16.0.0 has been released on March 18, while Rust 1.70 will become stable on June 1.
Tested images:
dist-x86_64-linux,dist-riscv64-linux(alt),dist-x86_64-illumos,dist-various-1,dist-various-2,dist-powerpc-linux,wasm32,armhf-gnuTested images until the usual IPv6 failures:
test-various