bcm5719-llvm - Project Ortega BCM5719 LLVM

	Commit message (Collapse)	Author	Age	Files	Lines
*	Use private linkage for utf-16 objc strings too.	Rafael Espindola	2014-01-21	1	-1/+1
\| \| \| \|	llvm-svn: 199709
*	Give explicit sections for string constants used in NSStrings.	Rafael Espindola	2014-01-20	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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
*	The UTF16 string referenced by a CFString should go into the __TEXT,__ustring	Bill Wendling	2012-03-30	1	-0/+10
	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