llvm-svn: 136209

- Replace calling -zone with 'nil'. -zone is obsolete in ARC.
- Allow removing retain/release on a static global var.
- Fix assertion hit when scanning for name references outside a NSAutoreleasePool scope.
- Automatically add bridged casts for results of objc method calls and when calling CFRetain, for example:

NSString *s;
CFStringRef ref = [s string];   -> CFStringRef ref = (__bridge CFStringRef)([s string]);
ref = s.string;                 -> ref = (__bridge CFStringRef)(s.string);
ref = [NSString new];           -> ref = (__bridge_retained CFStringRef)([NSString new]);
ref = [s newString];            -> ref = (__bridge_retained CFStringRef)([s newString]);
ref = [[NSString alloc] init];  -> ref = (__bridge_retained CFStringRef)([[NSString alloc] init]);
ref = [[s string] retain];      -> ref = (__bridge_retained CFStringRef)([s string]);
ref = CFRetain(s);              -> ref = (__bridge_retained CFTypeRef)(s);
ref = [s retain];               -> ref = (__bridge_retained CFStringRef)(s);

- Emit migrator error when trying to cast to CF type the result of autorelease/release:
  for

CFStringRef f3() {
  return (CFStringRef)[[[NSString alloc] init] autorelease];
}

emits:

t.m:12:10: error: [rewriter] it is not safe to cast to 'CFStringRef' the result of 'autorelease' message; a __bridge cast may result in a pointer to a destroyed object and a __bridge_retained may leak the object
  return (CFStringRef)[[[NSString alloc] init] autorelease];
         ^            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t.m:12:3: note: [rewriter] remove the cast and change return type of function to 'NSString *' to have the object automatically autoreleased
  return (CFStringRef)[[[NSString alloc] init] autorelease];
  ^

- Before changing attributes to weak/unsafe_unretained, check if the backing ivar
  is set to a +1 object, in which case use 'strong' instead.

llvm-svn: 136208

llvm-svn: 136207

llvm-svn: 136206

llvm-svn: 136205

for-in statements;  specifically, make sure to close over any
temporaries or cleanups it might require.  In ARC, this has
implications for the lifetime of the collection, so emit it
with a retain and release it upon exit from the loop.

rdar://problem/9817306

llvm-svn: 136204

In Microsoft mode, if we are within a templated function and we can't resolve Identifier during BuildCXXNestedNameSpecifier, then extend the SS with Identifier. This will have  the effect of resolving Identifier during template instantiation.  The goal is to be able to resolve a function call whose nested-name-specifier is located inside a dependent base class.

class C {
public:
    static void foo2() {  }
};

template <class T> class A {
public:
   typedef C D;
};

template <class T> class B : public A<T> {
public:
  void foo() { D::foo2(); }
};

Note that this won't work if the NestedNameSpecifier refers to a type.
This fixes 1 error when parsing the MSVC 2010 standard headers file with clang.

llvm-svn: 136203

llvm-svn: 136202

llvm-svn: 136201

usage of the shuffle bitmask. Both work in 128-bit lanes without
crossing, but in the former the mask of the high part is the same
used by the low part while in the later both lanes have independent
masks. Handle this properly and and add support for vpermilpd.

llvm-svn: 136200

llvm-svn: 136199

Fix AliasSetTracker so that it doesn't make any assumptions about instructions it doesn't know about (like the atomic instructions I'm adding).

llvm-svn: 136198

llvm-svn: 136197

It is quiet possible that inlined function body is split into multiple chunks of consequtive instructions. But, there is not any way to describe this in .debug_inline accelerator table used by gdb. However, describe non contiguous ranges of inlined function body appropriately using AT_range of DW_TAG_inlined_subroutine debug info entry.

llvm-svn: 136196

llvm-svn: 136194

they're still wanted.

llvm-svn: 136193

llvm-svn: 136192

to clang now, the rest are in process (6) or have been deleted.

llvm-svn: 136191

This required converting the StringMaps to use a BumpPtrAllocator.  I measured the
compile time and saw no observable regression.

llvm-svn: 136190

llvm-svn: 136189

llvm-svn: 136188

llvm-svn: 136187

When splitting global live ranges, it is now possible to split for
multiple destination intervals at once. Previously, we only had the main
and stack intervals.

Each edge bundle is assigned to a split candidate, and splitAroundRegion
will insert copies between the candidate intervals and the stack
interval as needed.

The multi-way splitting is used to split around compact regions when
enabled with -compact-regions. The best candidate register still gets
all the bundles it wants, but everything outside the main interval is
first split around compact regions before we create single-block
intervals.

Compact region splitting still causes some regressions, so it is not
enabled by default.

llvm-svn: 136186

llvm-svn: 136185

llvm-svn: 136184

llvm-svn: 136183

llvm-svn: 136182

[dcl.init.list] as is possible without generalized initializer lists or full
constant expression support, and adds a c++0x-compat warning in C++98 mode.

The FixIt currently uses a typedef's basename without qualification, which is
likely to be incorrect on some code.  If it's incorrect on too much code, we
should write a function to get the string that refers to a type from a
particular context.

The warning is currently off by default. I'll fix LLVM and clang before turning
it on.

llvm-svn: 136181

destructors of abstract classes. It's undefined behavior to actually
call the destructor (e.g., via delete), but the presence of code that
calls this destructor doesn't make the program
ill-formed. Fixes <rdar://problem/9819242>.

llvm-svn: 136180

llvm-svn: 136179

llvm-svn: 136178

llvm-svn: 136177

These copies would coalesce easily, but the resulting value would be
defined by a deleted instruction. Now we also remove the undefined value
number from the destination register.

This fixes PR10503.

llvm-svn: 136174

llvm-svn: 136173

I'm not completely sure the standard allows us to reject this, but if it doesn't, it should. :)

llvm-svn: 136172

llvm-svn: 136170

llvm-svn: 136169

llvm-svn: 136168

On x86 we can't encode an immediate LHS of a sub directly. If the RHS comes from a XOR with a constant we can
fold the negation into the xor and add one to the immediate of the sub. Then we can turn the sub into an add,
which can be commuted and encoded efficiently.

This code is generated for __builtin_clz and friends.

llvm-svn: 136167

build bots.

llvm-svn: 136166