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/constant-strings.m

32 lines
1.8 KiB
Mathematica
Raw Normal View History

test: add explicit targets for some tests These tests currently expect MachO section names and do not provide a target. Explicitly provide one. llvm-svn: 271212
2016-05-31 00:36:48 +08:00
// REQUIRES: x86-registered-target
// RUN: %clang_cc1 -triple x86_64-macho -emit-llvm -o %t %s
IRgen/Obj-C: Emit CFStrings and NSStrings with the alignment of the char type, there is no reason to align them higher. - This roughly matches llvm-gcc's r126913. - It is an open question whether or not we should do this for cstring's in general (code size vs optimization potential), for now we just match llvm-gcc until someone wants to run some experiments. llvm-svn: 129410
2011-04-13 07:30:52 +08:00
// RUN: FileCheck --check-prefix=CHECK-NEXT < %t %s
Add some Objective-C code generation tests. - Note that these don't really test anything other than that code generation doesn't fail or crash. Better than nothing though! llvm-svn: 55761
2008-09-04 12:36:23 +08:00
IRgen/Obj-C: Emit CFStrings and NSStrings with the alignment of the char type, there is no reason to align them higher. - This roughly matches llvm-gcc's r126913. - It is an open question whether or not we should do this for cstring's in general (code size vs optimization potential), for now we just match llvm-gcc until someone wants to run some experiments. llvm-svn: 129410
2011-04-13 07:30:52 +08:00
// Check that we set alignment 1 on the string.
//
Give explicit sections for string constants used in NSStrings. Without them they can be merged with non unnamed_addr constants during LTO. The resulting constant is not unnamed_addr and goes in a different section, which causes ld64 to crash. A testcase that would crash before: * file1.mm: void g(id notification) { [notification valueForKey:@"name"]; } * file2.cpp: extern const char js_name_str[] = "name"; * file3.cpp extern bool JS_GetProperty(const char *name); extern const char js_name_str[]; bool js_ReportUncaughtException() { JS_GetProperty(js_name_str); } run clang file1.mm -o file1.o -c -w -emit-llvm clang file2.cpp -o file2.o -c -w -emit-llvm clang file3.cpp -o file3.o -c -w ld -dylib -o XUL file1.o file2.o file3.o -undefined dynamic_lookup. llvm-svn: 199688
2014-01-21 04:33:18 +08:00
// CHECK-NEXT: @.str = {{.*}}constant [13 x i8] c"Hello World!\00", section "__TEXT,__cstring,cstring_literals", align 1
IRgen/Obj-C: Emit CFStrings and NSStrings with the alignment of the char type, there is no reason to align them higher. - This roughly matches llvm-gcc's r126913. - It is an open question whether or not we should do this for cstring's in general (code size vs optimization potential), for now we just match llvm-gcc until someone wants to run some experiments. llvm-svn: 129410
2011-04-13 07:30:52 +08:00
test: add explicit targets for some tests These tests currently expect MachO section names and do not provide a target. Explicitly provide one. llvm-svn: 271212
2016-05-31 00:36:48 +08:00
// RUN: %clang_cc1 -triple x86_64-macho -fobjc-runtime=gcc -emit-llvm -o %t %s
IRgen/Obj-C: Emit CFStrings and NSStrings with the alignment of the char type, there is no reason to align them higher. - This roughly matches llvm-gcc's r126913. - It is an open question whether or not we should do this for cstring's in general (code size vs optimization potential), for now we just match llvm-gcc until someone wants to run some experiments. llvm-svn: 129410
2011-04-13 07:30:52 +08:00
// RUN: FileCheck --check-prefix=CHECK-GNU < %t %s
// CHECK-GNU: NXConstantString
test: add explicit targets for some tests These tests currently expect MachO section names and do not provide a target. Explicitly provide one. llvm-svn: 271212
2016-05-31 00:36:48 +08:00
// RUN: %clang_cc1 -triple x86_64-macho -fobjc-runtime=gcc -fconstant-string-class NSConstantString -emit-llvm -o %t %s
IRgen/Obj-C: Emit CFStrings and NSStrings with the alignment of the char type, there is no reason to align them higher. - This roughly matches llvm-gcc's r126913. - It is an open question whether or not we should do this for cstring's in general (code size vs optimization potential), for now we just match llvm-gcc until someone wants to run some experiments. llvm-svn: 129410
2011-04-13 07:30:52 +08:00
// RUN: FileCheck --check-prefix=CHECK-GNU-WITH-CLASS < %t %s
// CHECK-GNU-WITH-CLASS: NSConstantString
Revert "Revert r332955 "GNUstep Objective-C ABI version 2"" llvm-svn: 332963
2018-05-22 18:13:06 +08:00
//
// RUN: %clang_cc1 -triple x86_64-unknown-freebsd -fobjc-runtime=gnustep-2.0 -emit-llvm -o %t %s
// RUN: FileCheck --check-prefix=CHECK-GNUSTEP2 < %t %s
Revert r332955 "GNUstep Objective-C ABI version 2" Reverted due to buildbot failures. Seems like isnumber() is some Apple addition to cctype. llvm-svn: 332957
2018-05-22 16:16:45 +08:00
Revert "Revert r332955 "GNUstep Objective-C ABI version 2"" llvm-svn: 332963
2018-05-22 18:13:06 +08:00
// CHECK-GNUSTEP2: @._OBJC_CLASS_NSConstantString = external global i8*
// CHECK-GNUSTEP2: @0 = private unnamed_addr constant [13 x i8] c"Hello World!\00", align 1
// CHECK-GNUSTEP2: @.objc_string = private global { i8**, i32, i32, i32, i32, i8* } { i8** @._OBJC_CLASS_NSConstantString, i32 0, i32 12, i32 12, i32 0, i8* getelementptr inbounds ([13 x i8], [13 x i8]* @0, i64 0, i64 0) }, section "__objc_constant_string", align 8
// CHECK-GNUSTEP2: @b = global i8* inttoptr (i64 -3340545023602065388 to i8*), align 8
// CHECK-GNUSTEP2: @.objc_str_Hello_World = linkonce_odr hidden global { i8**, i32, i32, i32, i32, i8* } { i8** @._OBJC_CLASS_NSConstantString, i32 0, i32 11, i32 11, i32 0, i8* getelementptr inbounds ([12 x i8], [12 x i8]* @1, i64 0, i64 0) }, section "__objc_constant_string", comdat, align 8
// CHECK-GNUSTEP2: @c =
// CHECK-SAME-GNUSTEP2: @.objc_str_Hello_World
//
id a = @"Hello World!";
id b = @"hi";
id c = @"Hello World";