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

19 lines
733 B
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
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
id a = @"Hello World!";