-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suspected LLVM miscompilation of bool to int cast #112170
Comments
Cleaned up input IR:
After
After llc:
So this looks like a backend bug. |
Yes it's an x86 backend bug llvm/llvm-project#63055 |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high +T-compiler |
Is this a regression (from-stable-to-stable?) |
@nagisa Since the Rust reproduction is in custom MIR, it's hard to test using older nightlies as a lot of expressions are only parsable recently. But on the LLVM side the bug existed since LLVM 9: https://godbolt.org/z/bvGWdvfvn, which Rust started using from 1.38.0 |
The reproduction is fuzzer-generated custom MIR then (somewhat) minimised. I couldn't rewrite it into surface Rust as there are back edges to non-dominating basic blocks (they can't be turned into surface Rust loops). It's possible that rustc considers such control flow invalid, though this is likely an LLVM miscompilation and such control flow is valid at LLVM IR level. Miri also does not complain.
The actual execution flow has no loops, all statements are executed only once. Indented BBs are not taken, but still required for the reproduction.
In Miri, the program is UB-free under both Stacked Borrows and Tree Borrows. The correct result is 1
at
-Copt-level>=2
, it prints 255, which is clearly wrong as the value came from a bool to int cast.-Zmir-opt-level>=1
prevents the miscompilation,-Cno-prepopulate-passes
also does. Implying either the generated IR has UB or this is a bug in LLVMOnly reproducible on x86_64 Linux, not Apple Silicon macOS
(This is still reproducible even with llvm/llvm-project@97f0e7b applied, so it's a separate bug)
I tried to get a standalone LLVM IR file using @Nilstrieb's approach in https://github.com/Nilstrieb/rlo-issue-112061 by having
print_var
in helper C code, but I couldn't reproduce the misoptimisation withllc
since the pre-populated passes from rustc are required for the reproduction, whichllc -On
does not replicate (or not in the same order)cc @nikic
The text was updated successfully, but these errors were encountered: