- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
Closed
Labels
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamRelevant to the language team
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.
sanmai-NL
Metadata
Metadata
Assignees
Labels
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamRelevant to the language team