xref: /llvm-project/clang/test/CodeGenOpenCLCXX/local_addrspace_init.clcpp (revision b9376915cf897e79a852497c60f18ddacb1830ae)
1d1c8a151SAnastasia Stulova// RUN: %clang_cc1 %s -triple spir -emit-llvm -O0 -o - | FileCheck %s
2d1c8a151SAnastasia Stulova
3d1c8a151SAnastasia Stulova// Test that we don't initialize local address space objects.
4d1c8a151SAnastasia Stulova//CHECK: @_ZZ4testE1i = internal addrspace(3) global i32 undef
5d1c8a151SAnastasia Stulova//CHECK: @_ZZ4testE2ii = internal addrspace(3) global %class.C undef
6d1c8a151SAnastasia Stulovaclass C {
7d1c8a151SAnastasia Stulova  int i;
8d1c8a151SAnastasia Stulova};
9d1c8a151SAnastasia Stulova
10d1c8a151SAnastasia Stulovakernel void test() {
11d1c8a151SAnastasia Stulova  __local int i;
12d1c8a151SAnastasia Stulova  __local C ii;
13d1c8a151SAnastasia Stulova  // FIXME: In OpenCL C we don't accept initializers for local
14d1c8a151SAnastasia Stulova  // address space variables. User defined initialization could
15d1c8a151SAnastasia Stulova  // make sense, but would it mean that all work items need to
16d1c8a151SAnastasia Stulova  // execute it? Potentially disallowing any initialization would
17*b9376915SBoaz Brickner  // make things easier and assignments can be used to set specific
18d1c8a151SAnastasia Stulova  // values. This rules should make it consistent with OpenCL C.
19d1c8a151SAnastasia Stulova  //__local C c();
20d1c8a151SAnastasia Stulova}
21