Closed
Description
This is a pretty subtle interaction of several things that produces code which causes a segmentation fault:
- A struct with
#[repr(simd)]. - A struct with a member.
- A method on that struct.
- Transmuting the result of a method call.
#![feature(repr_simd)]
#[repr(simd)] // Without #[repr(simd)], it works fine.
pub struct Mu64(pub u64, pub u64, pub u64, pub u64);
pub struct Trouble {
state: Mu64, // Without this field, it works fine.
}
impl Trouble {
pub fn new() -> Trouble {
Trouble {
state: Mu64(1, 2, 3, 4),
}
}
fn next(&self) -> Mu64 {
Mu64(1, 2, 3, 4)
}
pub fn invoke_doom(&self) -> [u32; 8] {
use std::mem::transmute;
// transmute(Mu64(1, 2, 3, 4)) instead of transmute(self.next()) works
// fine.
unsafe { transmute(self.next()) }
}
}
#[test]
fn this_causes_sigsegv() {
let mut trouble = Trouble::new();
println!("{}", trouble.invoke_doom()[0]);
}Now cargo test crashes with a segmentation fault. (The test program that is, not Cargo.) cargo test --release runs fine. It could be that this is working as intended, and this is what I get for using unsafe code, but it certainly surprises me.
Workaround for now: use transmute_copy instead of transmute.
Version: rustc 1.9.0-nightly (a43eb4e 2016-04-12). It also happened on an older nightly.