Change:
} } <del> fn install_llvm_file(builder: &Builder<'_>, source: &Path, destination: &Path) { </del> <ins> fn install_llvm_file( builder: &Builder<'_>, source: &Path, destination: &Path, install_symlink: bool, ) { </ins> if builder.config.dry_run() { return; } <del> builder.install(source, destination, 0o644); </del> <ins> if source.is_symlink() { // If we have a symlink like libLLVM-18.so -> libLLVM.so.18.1, install the target of the // symlink, which is what will actually get loaded at runtime. builder.install(&t!(fs::canonicalize(source)), destination, 0o644); if install_symlink { // If requested, also install the symlink. This is used by download-ci-llvm. let full_dest = destination.join(source.file_name().unwrap()); builder.copy(&source, &full_dest); } } else { builder.install(&source, destination, 0o644); } </ins> } /// Maybe add LLVM object files to the given destination lib-dir. Allows either static or dynamic linking. /// /// Returns whether the files were actually copied. <del> fn maybe_install_llvm(builder: &Builder<'_>, target: TargetSelection, dst_libdir: &Path) -> bool { </del> <ins> fn maybe_install_llvm( builder: &Builder<'_>, target: TargetSelection, dst_libdir: &Path, install_symlink: bool, ) -> bool { </ins> // If the LLVM was externally provided, then we don't currently copy // artifacts into the sysroot. This is not necessarily the right // choice (in particular, it will require the LLVM dylib to be in

Discussion:
Minimal reproducible example I expected to see this happen: cargo builds the example Instead, this happened: The last working compiler that I've tried was . I haven't attempted to bisect since then so there could be some compilers working after 2024-01-15.
Reduced: Does not reproduce on LLVM trunk.
Fixed by and already backported upstream.

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --While working on I noticed that some optimizations regressed after a rebase. The following should be a reduction. I tried this code: I expected to see this happen (beta): Instead, this happened (nightly): <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I was able to "fix" the nightly codegen to be identical to beta by adding to Probably some inlining change in llvm 18 ? :thinking:
cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Odd, changing to fixes it. But is supposed to have strictly more UB, i.e. let LLVM optimize more.
I think the the direct cause here is a correctness fix in LLVM 18 which ends up stripping more poison flags during certain loop transformations, and ends up (likely unnecessarily) dropping here. The reason why offsetfrom helps is that it allows making use of the flag earlier by transforming a into . This transform requires that the exact operation be sdiv or ashr -- presumably because GEP offsets are signed. But this is not actually required (). It works just as well with unsigned exact division. I'll see about fixing that.
Upstream patch:
Now this is just rude. Apparently LoopIdiomRecognize strips the flags -- without actually performing any transform. I think LIR does some speculative expansion and then drops instructions again, but this doesn't recover flag changes.
Upstream issue for LIR:
Looks like my reduction was insufficient. The example on godbolt does optimize now but the original code that I was working on still fails with the but optimizes properly with . I'll extract the IR from a codegen test.
unoptimized IR, using subptr: <details<summaryoptimized IR, using subptr, fails to eliminate loop</summary</details<details<summaryoptimized IR, using offset_from, eliminates the loop</summary</details
Can you please provide a Rust test case or unoptimized IR?
The text file above should contain unoptimized IR.

Oh sorry, totally missed the first line...
This optimizes with LLVM 19, presumably due to the fix for But this is too risky to backport.
Not sure how to confirm whether this is really fixed now or not.
I'll dedust my branch and check it locally.
triage: original repro indeed fixed, any news on that local check?
is working again.

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Can be seen in more detail in : ! ! This is a pretty low-level LLVM codegen error that does not really fit the bill of an internal compile error, as it happens at a layer below , but I picked this report template because it seems like a pretty "internal" issue with the Rust compiler nevertheless. I didn't dive into the precise cause of this error at all, but judging from the error messages, it seems related to generating bad LLVM IR for the crate. On my CI setup, the issue only happens for Linux and macOS x64 targets. Windows x64 and Linux and macOS AArch64 targets build fine. </p</details
How should one reproduce this? works fine for me (on x64 Linux).
Ah, I get the error with .
Repro: on Does not reproduce with LLVM trunk.
Looks like this has been fixed by
Thanks for looking into the issue! The reproduction step is indeed to run on the linked code. A works fine for me too.

Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high