llvm-svn: 165900

llvm-svn: 165885

llvm-svn: 165710

This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).

This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.

llvm-svn: 165626

Have 'addFnAttr' take the attribute enum value. Then have it build the attribute object and add it appropriately. No functionality change.

llvm-svn: 165596

opaque layer is responsible for knowing where that specific attribute is stored.

llvm-svn: 165489

llvm-svn: 165395

llvm-svn: 165343

observe their addresses (taking their address gives the vtable slot) so we are
free to merge their definitions.

llvm-svn: 164864

struct assignment.

llvm-svn: 164853

llvm-svn: 164726

llvm-svn: 163325

No functionality change.

llvm-svn: 162552

llvm-svn: 162361

[asan] If we are compiling with ASan, add metadata indicating dynamically initialized globals. Patch by Reid Watson, reviewed by Richard Smith

llvm-svn: 162259

llvm-svn: 161659

previous ResetObjCLayout calls since this is now handled in Sema.

Part of rdar://11842763

llvm-svn: 160527

llvm-svn: 160102

runtime to gnustep from gnu.  Fix EH for the GCC runtime.

llvm-svn: 159684

When we're looking for redeclarations which might provide a definition in CodeGen, make sure we examine all the redeclarations.  PR13252.

llvm-svn: 159586

This allows for setting the default TLS model. (PR9788)

llvm-svn: 159336

literal helper functions. All helper functions (global
and locals) use block_invoke as their prefix. Local literal
helper names are prefixed by their enclosing mangled function
names. Blocks in non-local initializers (e.g. a global variable 
or a C++11 field) are prefixed by their mangled variable name. 
The descriminator number added to end of the name starts off 
with blank (for first block) and _<N> (for the N+2-th block).

llvm-svn: 159206

llvm-svn: 159091

This adds support for the tls_model attribute. This allows the user to
choose a TLS model that is better than what LLVM would select by
default. For example, a variable might be declared as:

  __thread int x __attribute__((tls_model("initial-exec")));

if it will not be used in a shared library that is dlopen'ed.

This depends on LLVM r159077.

llvm-svn: 159078

target Objective-C runtime down to the frontend:  break this
down into a single target runtime kind and version, and compute
all the relevant information from that.  This makes it
relatively painless to add support for new runtimes to the
compiler.  Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime.  This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.

As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.

I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.

llvm-svn: 158793

__forceinline is a combination of the inline keyword and __attribute__((always_inline))

llvm-svn: 158653

initialization, and use that information to produce the right kind of
initialization during template instantiation.

llvm-svn: 158288

In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.

This rolls back r155808 and r155869.

Review by Doug Gregor incorporating feedback from Chandler Carruth.

llvm-svn: 158104

llvm-svn: 157557

Because in CUDA types do not have associated address spaces,
globals are declared in their "native" address space, and accessed
by bitcasting the pointer to address space 0.  This relies on address
space 0 being a unified address space.

llvm-svn: 157167

Currently cold functions are marked with the "optsize" attribute in CodeGen
so they are always optimized for size.  The hot attribute is just ignored,
LLVM doesn't have a way to express hotness at the moment.

llvm-svn: 156723

It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.

Reviewed by Eric Christopher.

llvm-svn: 156160

filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.

This change errs on the side of value, making op-> return T* and op* return
T&.

(reviewed by Richard Smith)

llvm-svn: 155808

llvm-svn: 155697

llvm-svn: 155430

llvm-svn: 154880

an explicit instance variable.

rdar://10590352

llvm-svn: 154481

These patches cause us to miscompile and/or reject code with static
function-local variables in an extern-C context. Previously, we were
papering over this as long as the variables are within the same
translation unit, and had not seen any failures in the wild. We still
need a proper fix, which involves mangling static locals inside of an
extern-C block (as GCC already does), but this patch causes pretty
widespread regressions. Firefox, and many other applications no longer
build.

Lots of test cases have been posted to the list in response to this
commit, so there should be no problem reproducing the issues.

llvm-svn: 153768

other things which might mess with the variable's type.

llvm-svn: 153733

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