maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenObjC/encode-test-5.m

22 lines
1.2 KiB
Mathematica
Raw Normal View History

FileCheck'ize CodeGenObjC test This fixes PR22437. llvm-svn: 227843
2015-02-03 03:30:54 +08:00
// RUN: %clang_cc1 -triple=x86_64-apple-darwin9 -emit-llvm -o - %s | FileCheck %s
Add @encode support for complex types. llvm-svn: 68729
2009-04-10 05:55:45 +08:00
FileCheck'ize CodeGenObjC test This fixes PR22437. llvm-svn: 227843
2015-02-03 03:30:54 +08:00
// CHECK-DAG: @[[complex_int:.*]] = private unnamed_addr constant [3 x i8] c"ji\00", align 1
// CHECK-DAG: @a = global i8* getelementptr inbounds ([3 x i8]* @[[complex_int]], i32 0, i32 0), align 8
Add @encode support for complex types. llvm-svn: 68729
2009-04-10 05:55:45 +08:00
char *a = @encode(_Complex int);
FileCheck'ize CodeGenObjC test This fixes PR22437. llvm-svn: 227843
2015-02-03 03:30:54 +08:00
// CHECK-DAG: @[[complex_float:.*]] = private unnamed_addr constant [3 x i8] c"jf\00", align 1
// CHECK-DAG: @b = global i8* getelementptr inbounds ([3 x i8]* @[[complex_float]], i32 0, i32 0), align 8
Add @encode support for complex types. llvm-svn: 68729
2009-04-10 05:55:45 +08:00
char *b = @encode(_Complex float);
FileCheck'ize CodeGenObjC test This fixes PR22437. llvm-svn: 227843
2015-02-03 03:30:54 +08:00
// CHECK-DAG: @[[complex_double:.*]] = private unnamed_addr constant [3 x i8] c"jd\00", align 1
// CHECK-DAG: @c = global i8* getelementptr inbounds ([3 x i8]* @[[complex_double]], i32 0, i32 0), align 8
Add @encode support for complex types. llvm-svn: 68729
2009-04-10 05:55:45 +08:00
char *c = @encode(_Complex double);
FileCheck'ize CodeGenObjC test This fixes PR22437. llvm-svn: 227843
2015-02-03 03:30:54 +08:00
// CHECK-DAG: @[[int_128:.*]] = private unnamed_addr constant [2 x i8] c"t\00", align 1
// CHECK-DAG: @e = global i8* getelementptr inbounds ([2 x i8]* @[[int_128]], i32 0, i32 0), align 8
initial support for __[u]int128_t, which should be basically compatible with VC++ and GCC. The codegen/mangling angle hasn't been fully ironed out yet. Note that we accept int128_t even in 32-bit mode, unlike gcc. llvm-svn: 70464
2009-04-30 10:43:43 +08:00
char *e = @encode(__int128_t);
FileCheck'ize CodeGenObjC test This fixes PR22437. llvm-svn: 227843
2015-02-03 03:30:54 +08:00
// CHECK-DAG: @[[uint_128:.*]] = private unnamed_addr constant [2 x i8] c"T\00", align 1
// CHECK-DAG: @f = global i8* getelementptr inbounds ([2 x i8]* @[[uint_128]], i32 0, i32 0), align 8
initial support for __[u]int128_t, which should be basically compatible with VC++ and GCC. The codegen/mangling angle hasn't been fully ironed out yet. Note that we accept int128_t even in 32-bit mode, unlike gcc. llvm-svn: 70464
2009-04-30 10:43:43 +08:00
char *f = @encode(__uint128_t);