simd_insert and simd_extract allow garbage data

[workingjubilee]

It appears that with simd_insert and simd_extract that I can produce garbage data in a way that is probably due to unsound OOB memory access. These are unsafe functions but the related simd_shuffle functions fail to monomorphize. Miri provokes an ICE. I thiiiink simd_extract and simd_insert might not require const arguments on purpose, but I believe something may need to be patched re: Miri. cc @RalfJung

I was in the middle of constructing tests for rustc's simd intrinsics. I tried this code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=dfc24d97ffa77e6fbd4a65c16b713cf9

#![allow(non_camel_case_types)]
#![feature(repr_simd, platform_intrinsics)]

#[repr(simd)]
#[derive(Copy, Clone, Debug)]
struct f32x4(f32, f32, f32, f32);

extern "platform-intrinsic" {
    pub fn simd_insert<T, E>(x: T, idx: u32, y: E) -> T;
    pub fn simd_extract<T, E>(x: T, idx: u32) -> E;
}

fn main() {
    let x = f32x4(-1.0, 0.0, f32::INFINITY, f32::NAN);
    unsafe {
    	let ins: f32x4 = simd_insert(x, 5, f32::NEG_INFINITY);
    	let ext: f32 = simd_extract(x, 9);
        println!("{:?}", x);   // f32x4(-1.0, 0.0, inf, NaN)
        println!("{:?}", ins); // f32x4(0.000000000000000000000000000000000000000000001, 0.0,
                               // 12499248000000000.0, 0.000000000000000000000000000000000000000045915)
        println!("{}", ext);   // 0.000000000000000000000000000000000000000030658
    }
}

I (perhaps overly naively) expected to see this happen: "failure to monomorphize because blah blah blah"
Instead, this happened: I got some totally wild garbage data!

rustc --version:

rustc 1.48.0-nightly (ef663a8a4 2020-09-30) running on x86_64-unknown-linux-gnu

The Miri ICE:

thread 'rustc' panicked at 'Index `5` must be in bounds of vector type `f32`: `[0, 4)`', /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/compiler/rustc_mir/src/interpret/intrinsics.rs:393:17

[tesuji]

@rustbot modify labels: requires-nightly

[RalfJung]

Yeah the Miri ICE should definitely be fixed.

I guess the question is whether these intrinsics should fail to monomorphize, or whether using them with OOB indices is UB. I assume the latter, but it would be good to get someone to confirm... who would know about SIMD stuff?

Also, this UB should be added to the docs for those intrinsics, probably in stdarch.

[bjorn3]

simd_shuffle checks if the indices are in bound:

rust/compiler/rustc_codegen_llvm/src/intrinsic.rs

Lines 882 to 902 in 6f56fbd

	let indices: Option<Vec<_>> = (0..n)
	.map(|i| {
	let arg_idx = i;
	let val = bx.const_get_elt(vector, i as u64);
	match bx.const_to_opt_u128(val, true) {
	None => {
	emit_error!("shuffle index #{} is not a constant", arg_idx);
	None
	}
	Some(idx) if idx >= total_len => {
	emit_error!(
	"shuffle index #{} is out of bounds (limit {})",
	arg_idx,
	total_len
	);
	None
	}
	Some(idx) => Some(bx.const_i32(idx as i32)),
	}
	})
	.collect();

The simd_insert and simd_extract intrinsics are codegened at

rust/compiler/rustc_codegen_llvm/src/intrinsic.rs

Lines 915 to 938 in 6f56fbd

	if name == sym::simd_insert {
	require!(
	in_elem == arg_tys[2],
	"expected inserted type `{}` (element of input `{}`), found `{}`",
	in_elem,
	in_ty,
	arg_tys[2]
	);
	return Ok(bx.insert_element(
	args[0].immediate(),
	args[2].immediate(),
	args[1].immediate(),
	));
	}
	if name == sym::simd_extract {
	require!(
	ret_ty == in_elem,
	"expected return type `{}` (element of input `{}`), found `{}`",
	in_elem,
	in_ty,
	ret_ty
	);
	return Ok(bx.extract_element(args[0].immediate(), args[1].immediate()));
	}

[bjorn3]

@rustbot modify labels: +A-simd +A-codegen +T-compiler

[RalfJung]

The insert and extract intrinsics do not even have rustc_args_required_cons, so they cannot be checked at monmorphization time. Thus UB is likely the only option.

[bjorn3]

That is just an oversight in stdarch. All users of it are constant. (either fixed or using the constify family of macros)

[RalfJung]

Well, but codegen does not seem to rely on them being constants either, so why would we require that?

[bjorn3]

While LLVM allows variable indexes, it will generate way more efficient code when indexes are known at compile time. https://godbolt.org/z/zvorEa Other codegen backends, like cg_clif, may also not allow variable indexes.