authorgravatar for thatlemon@gmail.comLemonBoy <thatlemon@gmail.com> 2020-10-16 12:15:46+02:00
committergravatar for andrew@ziglang.orgAndrew Kelley <andrew@ziglang.org> 2020-10-16 18:39:48-04:00
logf78380b936de862476ea6b3cc3e8d4ba4562c7fa
tree3c4280298a9005d320b8a2dcddb157f3e261cf1d
parent2a62d4b20be9b99f53367e74434e1971ced78848

stage1: Don't ask LLVM to emit misaligned memcpy

Pay close attention to the RHS type alignment when rendering an assignment op as it may differ from the LHS pointer one. This problem was noticed when debugging a CI failure in #6648: due to sheer luck the misalignment caused a segfault on macos that was also reproduced locally. I tried to write a small test case but it turned out to be a daunting task as I couldn't manage to trigger the problem consistently (and stop the optimizer from simplifying everything). Patches welcome.

1 files changed, 5 insertions(+), 3 deletions(-)

src/stage1/codegen.cpp+5-3
......@@ -1645,11 +1645,13 @@ static void gen_assign_raw(CodeGen *g, LLVMValueRef ptr, ZigType *ptr_type,
16451645
16461646 ZigType *usize = g->builtin_types.entry_usize;
16471647 uint64_t size_bytes = LLVMStoreSizeOfType(g->target_data_ref, get_llvm_type(g, child_type));
1648 uint64_t align_bytes = get_ptr_align(g, ptr_type);
1648 uint64_t src_align_bytes = get_abi_alignment(g, child_type);
1649 uint64_t dest_align_bytes = get_ptr_align(g, ptr_type);
16491650 assert(size_bytes > 0);
1650 assert(align_bytes > 0);
1651 assert(src_align_bytes > 0);
1652 assert(dest_align_bytes > 0);
16511653
1652 ZigLLVMBuildMemCpy(g->builder, dest_ptr, align_bytes, src_ptr, align_bytes,
1654 ZigLLVMBuildMemCpy(g->builder, dest_ptr, dest_align_bytes, src_ptr, src_align_bytes,
16531655 LLVMConstInt(usize->llvm_type, size_bytes, false),
16541656 ptr_type->data.pointer.is_volatile);
16551657 return;