transmute + tuple access + eq on repr(simd)'s inner value seems UB to valgrind

[celinval]

I tried this code:

#![feature(repr_simd)]
use std::mem::transmute;

#[derive(Clone, Debug)]
#[repr(simd)]
struct CustomSimd<T, const LANES: usize>([T; LANES]);

fn main() {
    let mut input : CustomSimd<u8, 10> = CustomSimd([0u8; 10]);
    input.0[0] = u8::MAX;
    let data = unsafe { transmute::<_, CustomSimd<u8, 10>>(input).0 };
    assert_eq!(data, [u8::MAX, 0, 0, 0, 0, 0, 0, 0, 0, 0]);
}

I expected to see this happen: I expected this test to succeed since the destination type is the same as the source type.

Instead, this happened: This test fails. When running it with valgrind, I get errors such as:

Conditional jump or move depends on uninitialised value(s)

Meta

I used the playground version:

Nightly channel
Build using the Nightly version: 1.72.0-nightly
(2023-07-06 85bf07972a1041b9e253)

[celinval]

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=524cbac77b9d6f2a60c39337fcbeb848

[saethlin]

This sounds like a repeat of rust-lang/portable-simd#339 (we don't have an issue for the problem just a PR for a fix, the report is on Zulip)

[workingjubilee]

When we finish removing the SIMD tuples, we should catch attempting to use .N to extract an inner value from these types during lowering.

rust/library/portable-simd/crates/core_simd/src/vector.rs

Lines 96 to 105 in eee6b31

	//
	// NOTE: Accessing the inner array directly in any way (e.g. by using the `.0` field syntax) or
	// directly constructing an instance of the type (i.e. `let vector = Simd(array)`) should be
	// avoided, as it will likely become illegal on `#[repr(simd)]` structs in the future. It also
	// causes rustc to emit illegal LLVM IR in some cases.
	#[repr(simd)]
	pub struct Simd<T, const N: usize>([T; N])
	where
	LaneCount<N>: SupportedLaneCount,
	T: SimdElement;

[workingjubilee]

@celinval Could you explain your use case for wanting Simd<u8, 10> specifically?

[celinval]

@celinval Could you explain your use case for wanting Simd<u8, 10> specifically?

Yes, sorry, I know it's a very specialized use case. I am trying to model simd_bitmask intrinsic inside our software verification tool (Kani). I was attempting to create a function that could be used wherever the intrinsic is used.

In my implementation, I was using transmute to extract the content of the Simd structure, so I was trying to transmute the input into a Simd structure I own (with the same layout). The code crashed when I tried to do that though. While debugging, I realized that even transmuting the Simd structure to the original one triggered UB. Hence, this issue.

[celinval]

When we finish removing the SIMD tuples, we should catch attempting to use .N to extract an inner value from these types during lowering.

I'm not sure I understand the tuple access part. I'm assuming you mean the member access, right? Is that also being removed?

This sounds like a repeat of rust-lang/portable-simd#339 (we don't have an issue for the problem just a PR for a fix, the report is on Zulip)

Yes, that seems like a similar problem. I will try the workaround from the PR you mentioned. Thanks

edit: @workingjubilee

[workingjubilee]

I'm not sure I understand the tuple access part. I'm assuming you mean the member access, right? Is that also being removed?

Yes, we are discussing it, as repr(simd) has some of the same... "philosophical problems" as repr(packed) did. It isn't immediately unsound, like with repr(packed), which allowed creating references that weren't actually aligned (and alignment is normally a property of references). However, inspecting the inner array of a repr(simd) type directly via member access can easily cause codegen problems which lead to miscompilations.

[celinval]

@workingjubilee should I leave this issue open till then?

[scottmcm]

@celinval rust-lang/compiler-team#838 is proposing to just ban that .0 on the simd type. Are you ok with that "fix" to this bug?

[TDecking]

The snippet currently makes rustc panic with the following backtrace:

error: internal compiler error: /rustc/f8a913b1381e90379c7ca63ac2b88b9518936628/compiler/rustc_codegen_ssa/src/mir/operand.rs:374:17: Non-ref type OperandRef(Immediate((<10 x i8>:  %7 = load <10 x i8>, ptr %5, align 16, !dbg !82)) @ TyAndLayout { ty: CustomSimd<u8, 10>, layout: Layout { size: Size(16 bytes), align: AbiAndPrefAlign { abi: Align(16 bytes), pref: Align(16 bytes) }, abi: Vector { element: Initialized { value: Int(I8, false), valid_range: 0..=255 }, count: 10 }, fields: Arbitrary { offsets: [Size(0 bytes)], memory_index: [0] }, largest_niche: None, uninhabited: false, variants: Single { index: 0 }, max_repr_align: None, unadjusted_abi_align: Align(16 bytes), randomization_seed: 71776127651151883 } }) cannot project to ref field type TyAndLayout { ty: [u8; 10], layout: Layout { size: Size(10 bytes), align: AbiAndPrefAlign { abi: Align(1 bytes), pref: Align(1 bytes) }, abi: Memory { sized: true }, fields: Array { stride: Size(1 bytes), count: 10 }, largest_niche: None, uninhabited: false, variants: Single { index: 0 }, max_repr_align: None, unadjusted_abi_align: Align(1 bytes), randomization_seed: 71776127651151883 } }


thread 'rustc' panicked at /rustc/f8a913b1381e90379c7ca63ac2b88b9518936628/compiler/rustc_codegen_ssa/src/mir/operand.rs:374:17:
Box<dyn Any>
stack backtrace:
   0:     0x704ed0b7e934 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hd7be009937be2364
   1:     0x704ed12162ec - core::fmt::write::h0544acec2ec24119
   2:     0x704ed227ffd1 - std::io::Write::write_fmt::h10bc0bac9b906282
   3:     0x704ed0b7e792 - std::sys::backtrace::BacktraceLock::print::hda023a2509f00ee5
   4:     0x704ed0b80f9e - std::panicking::default_hook::{{closure}}::h8abd3a8b59b1c118
   5:     0x704ed0b80b74 - std::panicking::default_hook::h2cf246466ff6438d
   6:     0x704ecfcde847 - std[accca10dc0a32706]::panicking::update_hook::<alloc[f11052e4315e5ad4]::boxed::Box<rustc_driver_impl[84ec5ca0d509ea22]::install_ice_hook::{closure#1}>>::{closure#0}
   7:     0x704ed0b81813 - std::panicking::rust_panic_with_hook::hf16596913b37d3a5
   8:     0x704ecfd1a931 - std[accca10dc0a32706]::panicking::begin_panic::<rustc_errors[e877111233569b78]::ExplicitBug>::{closure#0}
   9:     0x704ecfd0ed46 - std[accca10dc0a32706]::sys::backtrace::__rust_end_short_backtrace::<std[accca10dc0a32706]::panicking::begin_panic<rustc_errors[e877111233569b78]::ExplicitBug>::{closure#0}, !>
  10:     0x704ecfd0eb27 - std[accca10dc0a32706]::panicking::begin_panic::<rustc_errors[e877111233569b78]::ExplicitBug>
  11:     0x704ecfd24331 - <rustc_errors[e877111233569b78]::diagnostic::BugAbort as rustc_errors[e877111233569b78]::diagnostic::EmissionGuarantee>::emit_producing_guarantee
  12:     0x704ed02f5d86 - rustc_middle[a4083da5e55b20b4]::util::bug::opt_span_bug_fmt::<rustc_span[95a776ae324b0a20]::span_encoding::Span>::{closure#0}
  13:     0x704ed02df25a - rustc_middle[a4083da5e55b20b4]::ty::context::tls::with_opt::<rustc_middle[a4083da5e55b20b4]::util::bug::opt_span_bug_fmt<rustc_span[95a776ae324b0a20]::span_encoding::Span>::{closure#0}, !>::{closure#0}
  14:     0x704ed02df0cb - rustc_middle[a4083da5e55b20b4]::ty::context::tls::with_context_opt::<rustc_middle[a4083da5e55b20b4]::ty::context::tls::with_opt<rustc_middle[a4083da5e55b20b4]::util::bug::opt_span_bug_fmt<rustc_span[95a776ae324b0a20]::span_encoding::Span>::{closure#0}, !>::{closure#0}, !>
  15:     0x704ece6eb720 - rustc_middle[a4083da5e55b20b4]::util::bug::bug_fmt
  16:     0x704ed2a385d5 - <rustc_codegen_ssa[dd8f51faffb0c189]::mir::operand::OperandRef<&rustc_codegen_llvm[e2870ff9ff1c717e]::llvm::ffi::Value>>::extract_field::<rustc_codegen_llvm[e2870ff9ff1c717e]::builder::GenericBuilder<rustc_codegen_llvm[e2870ff9ff1c717e]::context::CodegenCx>>.cold
  17:     0x704ed24bf558 - <rustc_codegen_ssa[dd8f51faffb0c189]::mir::FunctionCx<rustc_codegen_llvm[e2870ff9ff1c717e]::builder::GenericBuilder<rustc_codegen_llvm[e2870ff9ff1c717e]::context::CodegenCx>>>::codegen_operand
  18:     0x704ed21463d3 - rustc_codegen_ssa[dd8f51faffb0c189]::mir::codegen_mir::<rustc_codegen_llvm[e2870ff9ff1c717e]::builder::GenericBuilder<rustc_codegen_llvm[e2870ff9ff1c717e]::context::CodegenCx>>
  19:     0x704ed212485b - rustc_codegen_llvm[e2870ff9ff1c717e]::base::compile_codegen_unit::module_codegen
  20:     0x704ed211cf90 - <rustc_codegen_llvm[e2870ff9ff1c717e]::LlvmCodegenBackend as rustc_codegen_ssa[dd8f51faffb0c189]::traits::backend::ExtraBackendMethods>::compile_codegen_unit
  21:     0x704ed21191d1 - <rustc_codegen_llvm[e2870ff9ff1c717e]::LlvmCodegenBackend as rustc_codegen_ssa[dd8f51faffb0c189]::traits::backend::CodegenBackend>::codegen_crate
  22:     0x704ed209165b - <rustc_interface[feb5976f8f8273df]::queries::Linker>::codegen_and_build_linker
  23:     0x704ed2336e6f - rustc_interface[feb5976f8f8273df]::passes::create_and_enter_global_ctxt::<core[437f1a36eb5747a6]::option::Option<rustc_interface[feb5976f8f8273df]::queries::Linker>, rustc_driver_impl[84ec5ca0d509ea22]::run_compiler::{closure#0}::{closure#2}>::{closure#2}::{closure#0}
  24:     0x704ed232a6e0 - rustc_interface[feb5976f8f8273df]::interface::run_compiler::<(), rustc_driver_impl[84ec5ca0d509ea22]::run_compiler::{closure#0}>::{closure#1}
  25:     0x704ed218a5c8 - std[accca10dc0a32706]::sys::backtrace::__rust_begin_short_backtrace::<rustc_interface[feb5976f8f8273df]::util::run_in_thread_with_globals<rustc_interface[feb5976f8f8273df]::util::run_in_thread_pool_with_globals<rustc_interface[feb5976f8f8273df]::interface::run_compiler<(), rustc_driver_impl[84ec5ca0d509ea22]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()>
  26:     0x704ed218a9f4 - <<std[accca10dc0a32706]::thread::Builder>::spawn_unchecked_<rustc_interface[feb5976f8f8273df]::util::run_in_thread_with_globals<rustc_interface[feb5976f8f8273df]::util::run_in_thread_pool_with_globals<rustc_interface[feb5976f8f8273df]::interface::run_compiler<(), rustc_driver_impl[84ec5ca0d509ea22]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()>::{closure#1} as core[437f1a36eb5747a6]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  27:     0x704ed218b36b - std::sys::pal::unix::thread::Thread::new::thread_start::ha0423521f81e2b75
  28:     0x704ed38a9a94 - <unknown>
  29:     0x704ed3936a34 - clone
  30:                0x0 - <unknown>

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: please make sure that you have updated to the latest nightly

note: please attach the file at `/playground/rustc-ice-2025-02-24T16_52_23-22.txt` to your bug report

note: compiler flags: --crate-type bin -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2

note: some of the compiler flags provided by cargo are hidden

[scottmcm]

That's by design, from #137361 -- make it ICE instead of be UB :P