================
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -emit-llvm
-disable-llvm-passes -o - %s | FileCheck %s --enable-var-scope
+
+// CHECK-LABEL: define void {{.*}}arr_assign1
+// CHECK: [[Arr:%.*]] = alloca [2 x i32], align 4
+// CHECK: [[Arr2:%.*]] = alloca [2 x i32], align 4
+// CHECK: [[Tmp:%.*]] = alloca [2 x i32], align 4
+// CHECK: call void @llvm.memcpy.p0.p0.i32(ptr align 4 [[Arr]], ptr align 4
{{@.*}}, i32 8, i1 false)
+// CHECK: call void @llvm.memset.p0.i32(ptr align 4 [[Arr2]], i8 0, i32 8, i1
false)
+// CHECK: call void @llvm.memcpy.p0.p0.i32(ptr align 4 [[Arr]], ptr align 4
[[Arr2]], i32 8, i1 false)
+// CHECK: call void @llvm.memcpy.p0.p0.i32(ptr align 4 [[Tmp]], ptr align 4
[[Arr]], i32 8, i1 false)
----------------
bogner wrote:
Ah, yeah. We do want to make sure that the assignment returns an lvalue and if
we try to use it in an rvalue context it goes through an lvalue-to-rvalue
conversion to do so. The PR as is seems to result in a jumble of C and C++
semantics, which is why it ends up doing these silly things.
It may be instructional to look at [an example with
pointers](https://godbolt.org/z/6f3rq7r53) and [one with structs](
https://godbolt.org/z/8ex335r7W). Specifically, in the AST view you can see the
LValueToRValue casts in these. Note that the struct case (the latter) is
probably a bit closer semantically, but since it ends up using a call to
`operator=` on the struct it's a bit harder to see what's going on. The pointer
case (the former) is a little bit cleaner with respect to being able to read
the AST output.
https://github.com/llvm/llvm-project/pull/109323
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
