maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/utf16-cfstrings.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

11 lines
377 B
C
Raw Normal View History

The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck %s
// <rdar://problem/10655949>
Use private linkage for utf-16 objc strings too. llvm-svn: 199709
2014-01-21 10:57:56 +08:00
// CHECK: @.str = private unnamed_addr constant [9 x i16] [i16 252, i16 98, i16 101, i16 114, i16 104, i16 117, i16 110, i16 100, i16 0], section "__TEXT,__ustring", align 2
The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> llvm-svn: 153710
2012-03-30 08:26:17 +08:00
#define CFSTR __builtin___CFStringMakeConstantString
void foo() {
CFSTR("überhund");
}