================ @@ -1710,7 +1710,7 @@ struct float16_int64_s f_ret_float16_int64_s(void) { // LP64: entry: // // LP64F-LP64D-LABEL: define dso_local void @f_float16_int64bf_s_arg -// LP64F-LP64D-SAME: (half [[TMP0:%.*]], i64 [[TMP1:%.*]]) #[[ATTR0]] { ---------------- topperc wrote:
I looked at the current IR for this. We have ``` %struct.float16_int64bf_s = type <{ half, i32, [2 x i8] }> define dso_local void @f_float16_int64bf_s_arg(half %0, i64 %1) #0 !dbg !1528 { %3 = alloca %struct.float16_int64bf_s, align 8 %4 = getelementptr inbounds nuw <{ half, i64 }>, ptr %3, i32 0, i32 0 store half %0, ptr %4, align 8 %5 = getelementptr inbounds nuw <{ half, i64 }>, ptr %3, i32 0, i32 1 store i64 %1, ptr %5, align 2 #dbg_declare(ptr %3, !1535, !DIExpression(), !1536) ret void, !dbg !1537 } ``` The struct type for the alloca is packed so it takes 8 bytes. Then we treat it as a packed struct of 10 bytes when we do the stores. So the i64 store went past the allocated memory. https://github.com/llvm/llvm-project/pull/110690 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits