lto = "thin" causes doctest to generate invalid code on rust-1.57
#92869
Comments
|
Also tried rust nightly on Ubuntu 21.10. Same crash. |
|
Can replicate on windows-msvc |
|
Regression in |
|
Bisect is pointing you to #89802, but the similar #91671 found that this was because Cargo changed whether LTO is applied to doctests. The actual compiler issue is probably a more general LTO thing, not Cargo's fault. On the rayon issue I supposed that this might have the same root cause as #91671, but the symptoms are different. |
|
Here's the codegen I get: 0000000000007010 <std::thread::local::LocalKey<T>::with>:
7010: 48 83 ec 18 sub $0x18,%rsp
7014: ff 17 call *(%rdi)
7016: 48 89 44 24 08 mov %rax,0x8(%rsp)
701b: 48 83 f8 00 cmp $0x0,%rax
701f: 75 2a jne 704b <std::thread::local::LocalKey<T>::with+0x3b>
7021: 48 8d 3d 2c 50 08 00 lea 0x8502c(%rip),%rdi # 8c054 <anon.dda6e9c32c792d26f11e51339977f165.0.llvm.9859745662360967200>
7028: 48 8d 0d 21 04 09 00 lea 0x90421(%rip),%rcx # 97450 <anon.dda6e9c32c792d26f11e51339977f165.3.llvm.9859745662360967200>
702f: 4c 8d 05 02 04 09 00 lea 0x90402(%rip),%r8 # 97438 <anon.dda6e9c32c792d26f11e51339977f165.2.llvm.9859745662360967200>
7036: 48 8d 05 33 2f 00 00 lea 0x2f33(%rip),%rax # 9f70 <core::result::unwrap_failed>
703d: be 46 00 00 00 mov $0x46,%esi
7042: 48 8d 54 24 10 lea 0x10(%rsp),%rdx
7047: ff d0 call *%rax
7049: 0f 0b ud2
704b: 48 8b 7c 24 08 mov 0x8(%rsp),%rdi
0000000000007050 <alloc::raw_vec::RawVec<T,A>::current_memory>:
[...]
0000000000007980 <bug::thread_func>:
7980: 48 8d 3d e9 fa 08 00 lea 0x8fae9(%rip),%rdi # 97470 <anon.dda6e9c32c792d26f11e51339977f165.3.llvm.9859745662360967200+0x20>
7987: e9 84 f6 ff ff jmp 7010 <std::thread::local::LocalKey<T>::with>
798c: 0f 1f 40 00 nopl 0x0(%rax)So |
cuviper
added
T-compiler
Aaron1011
added
the
I-unsound
rustbot
added
the
I-prioritize
|
The crate is compiled with |
|
Fixing option mismatch between Generally I would expect LTO to allow mixing different but ABI-compatible optimization levels. I don't know what docs say to guarantee. |
|
Here is a simpler program (no real thread locals) which also reproduces the issue: mod fake_thread_local {
pub struct LocalKey<T: 'static> {
pub get_value: fn() -> Option<&'static T>,
}
impl<T: 'static> LocalKey<T> {
pub fn with<F, R>(&'static self, f: F) -> R
where
F: FnOnce(&T) -> R,
{
self.try_with(f).expect("")
}
#[inline]
pub fn try_with<F, R>(&'static self, f: F) -> Option<R>
where
F: FnOnce(&T) -> R,
{
let fake_thread_local = (self.get_value)()?;
Some(f(fake_thread_local))
}
}
}
fn get_value() -> Option<&'static ()> {
Some(&())
}
const THREAD_LOCAL_GLOBAL: fake_thread_local::LocalKey<()> = fake_thread_local::LocalKey { get_value };
#[inline(never)]
fn set_state_func(_: &()) {
}
/// # Examples
///
/// ```
/// # fn main() {
/// bug::do_bug()
/// # }
/// ```
#[inline(never)]
pub fn do_bug() {
THREAD_LOCAL_GLOBAL.with(set_state_func);
} |
I think that has to be supported, because the prebuilt standard library may already have different options than your project. |
|
I think i narrowed down the problem to a llvm codegen issue. The problem can be reproduced with this file: bug.ll.gz. Compiling with 0000000000000000 <_ZN3bug17fake_thread_local17LocalKey$LT$T$GT$4with17hc98bdf741300d0b2E>:
0: 50 push %rax
1: ff 17 call *(%rdi)
3: 48 89 04 24 mov %rax,(%rsp)
7: 48 83 f8 00 cmp $0x0,%rax
b: 75 1e jne 2b <_ZN3bug17fake_thread_local17LocalKey$LT$T$GT$4with17hc98bdf741300d0b2E+0x2b>
d: 48 bf 00 00 00 00 00 movabs $0x0,%rdi
14: 00 00 00
17: 31 c0 xor %eax,%eax
19: 89 c6 mov %eax,%esi
1b: 48 ba 00 00 00 00 00 movabs $0x0,%rdx
22: 00 00 00
25: ff 15 00 00 00 00 call *0x0(%rip) # 2b <_ZN3bug17fake_thread_local17LocalKey$LT$T$GT$4with17hc98bdf741300d0b2E+0x2b>
2b: 48 8b 3c 24 mov (%rsp),%rdi |
|
Further reduced: https://gist.github.com/nikic/b6c45e5eeac03ef1fd842353815ceba4 It seems like all this takes is the combination of a tail call followed by dbg.value and FastISel :/ |
|
Filed llvm/llvm-project#53243. |
|
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-high |
rustbot
added
P-high
|
The fix has been pulled in by the LLVM 14 upgrade. I've verified this works on beta. |
|
Would it be fair to say it's a cargo bug that |
It's a senf-contained example extracted from rayon-rs/rayon#911 where doctest tests mysteriously crash
rav1e. This is what crashes for me:It needs the following
Cargo.toml:Running the test:
I expected to see this happen: test should pass and not crash.
Instead, this happened: test crashes mysteriously.
Meta
rustc --version --verbose:Backtrace
The text was updated successfully, but these errors were encountered: