================
@@ -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)
----------------
llvm-beanz wrote:
I think the code as implemented by this PR is still wrong. The tmp isn't the
lvalue of the left hand operand, we're falling into a weird spot that hits C
codegen behavior rather than C++.
The assignment operator is returning a temporary copy of the left hand value.
This is because in C the value of an assignment is the non-lvalue value. We get
here because C++ doesn't allow assignment operators on aggregates except when
the operator is a resolved CXX operator.
A test case that illustrates the problem is:
```hlsl
export int fn() {
int Arr[2] = {0, 1};
int Arr2[2] = {1, 2};
(Arr = Arr2)[0] = 6;
return Arr[0] + Arr[1];
}
```
The return result here should be 7, but instead it is 3.
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
