Change:
val: &'ll Value, dst: PlaceRef<'tcx, &'ll Value>, ) { <del> if self.is_ignore() { return; } if self.is_sized_indirect() { OperandValue::Ref(val, None, self.layout.align.abi).store(bx, dst) } else if self.is_unsized_indirect() { bug!("unsized `ArgAbi` must be handled through `store_fn_arg`"); } else if let PassMode::Cast { cast, pad_i32: _ } = &self.mode { // FIXME(eddyb): Figure out when the simpler Store is safe, clang // uses it for i16 -> {i8, i8}, but not for i24 -> {i8, i8, i8}. let can_store_through_cast_ptr = false; if can_store_through_cast_ptr { bx.store(val, dst.llval, self.layout.align.abi); } else { // The actual return type is a struct, but the ABI // adaptation code has cast it into some scalar type. The // code that follows is the only reliable way I have // found to do a transform like i64 -> {i32,i32}. // Basically we dump the data onto the stack then memcpy it. // // Other approaches I tried: // - Casting rust ret pointer to the foreign type and using Store //   is (a) unsafe if size of foreign type > size of rust type and //   (b) runs afoul of strict aliasing rules, yielding invalid //   assembly under -O (specifically, the store gets removed). // - Truncating foreign type to correct integral type and then //   bitcasting to the struct type yields invalid cast errors. // We instead thus allocate some scratch space... let scratch_size = cast.size(bx); let scratch_align = cast.align(bx); let llscratch = bx.alloca(cast.llvm_type(bx), scratch_align); bx.lifetime_start(llscratch, scratch_size); // ... where we first store the value... bx.store(val, llscratch, scratch_align); // ... and then memcpy it to the intended destination. bx.memcpy( dst.llval, self.layout.align.abi, llscratch, scratch_align, bx.const_usize(self.layout.size.bytes()), MemFlags::empty(), ); </del> <ins> match &self.mode { PassMode::Ignore => {} // Sized indirect arguments PassMode::Indirect { attrs, meta_attrs: None, on_stack: _ } => { let align = attrs.pointee_align.unwrap_or(self.layout.align.abi); OperandValue::Ref(val, None, align).store(bx, dst); } // Unsized indirect qrguments PassMode::Indirect { attrs: _, meta_attrs: Some(_), on_stack: _ } => { bug!("unsized `ArgAbi` must be handled through `store_fn_arg`"); } PassMode::Cast { cast, pad_i32: _ } => { // FIXME(eddyb): Figure out when the simpler Store is safe, clang // uses it for i16 -> {i8, i8}, but not for i24 -> {i8, i8, i8}. let can_store_through_cast_ptr = false; if can_store_through_cast_ptr { bx.store(val, dst.llval, self.layout.align.abi); } else { // The actual return type is a struct, but the ABI // adaptation code has cast it into some scalar type. The // code that follows is the only reliable way I have // found to do a transform like i64 -> {i32,i32}. // Basically we dump the data onto the stack then memcpy it. // // Other approaches I tried: // - Casting rust ret pointer to the foreign type and using Store //   is (a) unsafe if size of foreign type > size of rust type and //   (b) runs afoul of strict aliasing rules, yielding invalid //   assembly under -O (specifically, the store gets removed). // - Truncating foreign type to correct integral type and then //   bitcasting to the struct type yields invalid cast errors. // We instead thus allocate some scratch space... let scratch_size = cast.size(bx); let scratch_align = cast.align(bx); let llscratch = bx.alloca(cast.llvm_type(bx), scratch_align); bx.lifetime_start(llscratch, scratch_size); // ... where we first store the value... bx.store(val, llscratch, scratch_align); // ... and then memcpy it to the intended destination. bx.memcpy( dst.llval, self.layout.align.abi, llscratch, scratch_align, bx.const_usize(self.layout.size.bytes()), MemFlags::empty(), ); </ins> <del> bx.lifetime_end(llscratch, scratch_size); </del> <ins> bx.lifetime_end(llscratch, scratch_size); } } _ => { OperandRef::from_immediate_or_packed_pair(bx, val, self.layout).val.store(bx, dst); </ins> } <del> } else { OperandRef::from_immediate_or_packed_pair(bx, val, self.layout).val.store(bx, dst); </del> } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Alignment requirements are upheld. Instead, this happened: is clearly not as we indicate. This is unsound. label I-unsound A-ffi This issue is somewhat similar to . The fix for that issue, , made this problem worse by causing Rust and alignments to differ in more cases. (That change is correct, because the Rust and alignment must differ to satisfy the ABI. It just uncovered this issue in more cases.) This is also similar to . However, unlike that one, this issue is practical (and easy) to fix. pointers are not exposed to Rust code, so we can just make a copy of the argument into a higher-aligned alloca, without breaking Rust semantics. In fact, we already do this in the reverse situation, when the Rust alignment is lower than the alignment (): <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I will open a fix for this shortly.
WG-prioritization assigning priority (). label -I-prioritize +P-high