================
@@ -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
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
