Anastasia Stulova | 88ed70e | 2019-07-25 11:04:29 +0000 | [diff] [blame] | 1 | // RUN: %clang_cc1 %s -triple spir -cl-std=clc++ -emit-llvm -O0 -o - | FileCheck %s |
Anastasia Stulova | 9b4c6b8 | 2019-04-04 11:08:51 +0000 | [diff] [blame] | 2 | |
| 3 | // Test that we don't initialize local address space objects. |
Anastasia Stulova | d6865b7 | 2019-05-07 14:22:34 +0000 | [diff] [blame] | 4 | //CHECK: @_ZZ4testE1i = internal addrspace(3) global i32 undef |
| 5 | //CHECK: @_ZZ4testE2ii = internal addrspace(3) global %class.C undef |
Anastasia Stulova | 9b4c6b8 | 2019-04-04 11:08:51 +0000 | [diff] [blame] | 6 | class C { |
| 7 | int i; |
| 8 | }; |
| 9 | |
| 10 | kernel void test() { |
| 11 | __local int i; |
| 12 | __local C ii; |
| 13 | // FIXME: In OpenCL C we don't accept initializers for local |
| 14 | // address space variables. User defined initialization could |
| 15 | // make sense, but would it mean that all work items need to |
| 16 | // execute it? Potentially disallowing any initialization would |
| 17 | // make things easier and assingments can be used to set specific |
| 18 | // values. This rules should make it consistent with OpenCL C. |
| 19 | //__local C c(); |
| 20 | } |