said group.  Also classify the group as a CompileOnly_Group so that this option
does not cause an unused argument warning when used with a link command.
rdar://11153013

llvm-svn: 153763

literals. // rdar://10803676

llvm-svn: 153756

the nested-name-specifier (e.g., because it is dependent), do not
error even though we can't represent it in the AST at this point.

This is a horrible, horrible hack. The actual feature we still need to
implement (for C++98!) is covered by PR12292. However, we used to
silently accept this code, so when we recently started rejecting it we
caused some regressions (e.g., <rdar://problem/11147355>). This hack
brings us back to the passable-but-not-good state we had previously.

llvm-svn: 153752

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

llvm-svn: 153733

Correctly check argument types for some vector macros in smmintrin.h. Put parentheses around uses of vector macro arguments.

llvm-svn: 153732

Fixes a false positive (radar://11152419). The current solution of
adding the info into 3 places is quite ugly. Pending a generic pointer
escapes callback.

llvm-svn: 153731

count.

This is an optimization for "retry without inlining" option. Here, if we
failed to inline a function due to reaching the basic block max count,
we are going to store this information and not try to inline it
again in the translation unit. This can be viewed as a function summary.

On sqlite, with this optimization, we are 30% faster then before and
cover 10% more basic blocks (partially because the number of times we
reach timeout is decreased by 20%).

llvm-svn: 153730

The way we handle this implicitly removes the ability to use
property l-values in this position, but that's really okay.

llvm-svn: 153729

llvm-svn: 153728

is causing the gdb test failures on the bots.

llvm-svn: 153727

llvm-svn: 153726

in ARC, under the usual reasoning limiting the use of __autoreleasing.

llvm-svn: 153725

llvm-svn: 153724

the case that the variable already exists.  Partly this is just
protection against people making crazy declarations with custom
asm labels or extern "C" names that intentionally collide with
the manglings of such variables, but the main reason is that we
can actually emit a static local variable twice with the
requirement that it match up.  There may be other cases with
(e.g.) the various nested functions, but the main exemplar is
with constructor variants, where we can be forced into
double-emitting the function body under certain circumstances
like (currently) the presence of virtual bases.

llvm-svn: 153723

inheritance.

llvm-svn: 153722

llvm-svn: 153721

ConstStructBuilder: fix offset math for base classes so it works correctly in general.  Found by inspection.

llvm-svn: 153720

Make sure we perform the relevant implied conversions correctly for ObjC methods with related result types. PR12384.

llvm-svn: 153716

llvm-svn: 153715

property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration.

Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart.

Fixes rdar://11026482

llvm-svn: 153714

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

reference is going to message the setter, the getter, or both.

Having this info on the ObjCPropertyRefExpr node makes it easier for AST
clients (like libclang) to reason about the meaning of the property reference.

[AST/Sema]
-Use 2 bits (with a PointerIntPair) in ObjCPropertyRefExpr to record the above info
-Have ObjCPropertyOpBuilder set the info appropriately.

[libclang]
-When there is an implicit property reference (property syntax using methods)
have clang_getCursorReferenced return a cursor for the method. If the property
reference is going to result in messaging both the getter and the setter choose
to return a cursor for the setter because it is less obvious from source inspection
that the setter is getting called.

The general idea has the seal of approval by John.

rdar://11151621

llvm-svn: 153709

its location the location of the property.

Part of rdar://11113120

llvm-svn: 153708

-the location of the cursor
-its extent
-its spelling

Part of radar://11113120

llvm-svn: 153707

Extend -Wc++11-narrowing to cover converted constant expressions as well as braced-initializers.  <rdar://problem/11121178>.

llvm-svn: 153703

Includes a test from a reported false positive fixed in some earlier
commit.

llvm-svn: 153702

llvm-svn: 153698

llvm-svn: 153678

llvm-svn: 153674

llvm-svn: 153673

llvm-svn: 153670

llvm-svn: 153669

LLVM intrinsics for.

I have an implementation of these functions, which wants to go in a libgcc_s
equivalent in compiler-rt.  It's currently here:

http://people.freebsd.org/~theraven/atomic.c

It will be committed to compiler-rt as soon as I work out where would be a
sensible place to put it...

llvm-svn: 153666

llvm-svn: 153665

visibility directives for a variety of exported
meta-data symbols. // rdar://11144048

llvm-svn: 153663

llvm-svn: 153660

in the property debug info. Any more isn't necessary after all.

rdar://11144023

llvm-svn: 153659

llvm-svn: 153658

llvm-svn: 153648

    http://llvm.org/docs/SourceLevelDebugging.html#objcproperty

    including type and DECL. Expand the getter and setter names
    into the fully qualified names.

    rdar://11144023

llvm-svn: 153640