================
@@ -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

Reply via email to