Miscompilation: comparing a pointer against all possible addresses returns `false`
Open
Nobody has claimed this yet.
A-LLVM
I-miscompile
I-unsound
P-low
T-compiler
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
Consider this code:
#![feature(strict_provenance)]
use std::ptr;
#[no_mangle]
pub fn test(x: *mut u8) -> bool {
let local = 0u8;
for i in 0..=usize::MAX {
if x.addr() == ptr::from_ref(&local).wrapping_add(i).addr() {
return true;
}
}
false
}
This compares x.addr() with every possible address there is. And yet, the optimized LLVM IR for this is:
; Function Attrs: mustprogress nofree norecurse nosync nounwind nonlazybind willreturn memory(none) uwtable
define noundef zeroext i1 @test(ptr nocapture noundef readnone %x) unnamed_addr #0 {
start:
ret i1 false
}
That's clearly nonsense.
This is the Rust version of https://github.com/llvm/llvm-project/issues/34450.
Cc @nikic @rust-lang/opsem
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by compiling the Rust reproducer in the issue and inspecting its optimized LLVM IR. Compare the behavior with LLVM issue 34450 and the strict-provenance pointer operations shown here. Done means the compiler no longer reduces this comparison over all possible addresses to an unconditional false result.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100