The code for looking up local/private method in Sema::ActOnInstanceMessage() was not handling categories properly. Sema::ActOnClassMessage() didn't have this bug.
Created a helper with the correct logic and changed both methods to use it.

llvm-svn: 65532

llvm-svn: 65530

llvm-svn: 65529

Also changed ObjCInterfaceDecl::lookupClassMethod() to look through a categories protocols.

Test/patch submitted by Jean-Daniel Dupas (thanks!).

llvm-svn: 65526

pretty sure we want to keep constant expression verification outside of 
Evaluate. Because of that, the short-circuit evaluation doesn't 
generally make sense, and the comma warning doesn't make sense in its 
current form.

llvm-svn: 65525

is a rather big change, but I think this is the direction we want to go; 
the code is significantly shorter now, and it doesn't duplicate Evaluate 
code.  There shouldn't be any visible changes as far as I know.

There has been some movement towards putting ICE handling into 
Evaluate (for example, VerifyIntegerConstantExpression uses Evaluate 
instead of isICE).  This patch is sort of the opposite of the approach, 
making ICE handling work without Evaluate being aware of it. I think 
this approach is better because it separates the code that does the 
constant evaluation from code that's calculating a rather 
arbitrary predicate.

The one thing I don't really like about this patch is that 
the handling of commas in C99 complicates it signficantly. (Seriously, 
what was the standards committee thinking when they wrote that 
part?) I think I've come up with a decent approach, but it doesn't feel
ideal.  I might add some way to check for evaluated commas from Evaluate 
in a subsequent patch; that said, it might not be worth bothering.

llvm-svn: 65524

llvm-svn: 65523

Don't ask me, how does this makefile-horribleness even work ;)

llvm-svn: 65522

llvm-svn: 65521

llvm-svn: 65520

llvm-svn: 65519

with the rest of the parallel directories.

Build lto when possible on all platforms. Make gold to explicitly depend on
libLTO.

llvm-svn: 65518

llvm-svn: 65517

llvm-svn: 65512

Next step: making them more coherent.

llvm-svn: 65511

 - <rdar://problem/6622451> Bad x86_64 code gen for message call taking one argument.

llvm-svn: 65510

conditional branch predecessors.

llvm-svn: 65509

llvm-svn: 65508

llvm-svn: 65507

llvm-svn: 65504

llvm-svn: 65503

anymore.  If we want to reuse bits and pieces to add strict checking for 
constant initializers, we can dig them out of SVN history; the existing 
code won't be useful as-is.

llvm-svn: 65502

llvm-svn: 65501

variable declarations where applicable.  Also, a few fixes to 
TryToFixInvalidVariablyModifiedType for issues that this exposed.

llvm-svn: 65500

ADDS{D|S}rr_Int and MULS{D|S}rr_Int are not commutable. The users of these intrinsics expect the high bits will not be modified.

llvm-svn: 65499

llvm-svn: 65498

If an available register falls through to a succ block, unset the last kill. Sorry, it's impossible to reduce a sensible test case. It basically requires the moon and stars to align in order to cause a failure.

llvm-svn: 65497

llvm-svn: 65496

llvm-svn: 65493

llvm-svn: 65489

derive from a class template specialization, e.g.,

  class B : public A<int> { };

llvm-svn: 65488

llvm-svn: 65487

llvm-svn: 65486

llvm-svn: 65485

  vector<vector<double>> Matrix;

In C++98/03, this token always means "right shift". However, if we're in
a context where we know that it can't mean "right shift", provide a
friendly reminder to put a space between the two >'s and then treat it
as two >'s as part of recovery.

In C++0x, this token is always broken into two '>' tokens.

llvm-svn: 65484

scan-build now looks for ccc-analyzer first in the 'bin' subdirectory and then the directory where scan-build lives.

llvm-svn: 65483

llvm-svn: 65482

overly long ints, e.g. i96, into pieces at PHIs
and the nodes that feed into them; however big-endian
reverses the order of the pieces (for some reason), and
wasn't doing it the same way on both sides, so
the pieces didn't match and runtime failures ensued.
Fixes 188.ammp and sqlite3 on ppc32.

llvm-svn: 65481

expressions of the form: 'short x = (y != 10);' While we handle 'int x = (y !=
10)' lazily, the cast to another integer type currently loses the symbolic
constraint. Eager evaluation of the constraint causes the paths to bifurcate and
eagerly evaluate 'y != 10' to a constant of 1 or 0. This should address
<rdar://problem/6619921> until we have a better (more lazy approach) for
handling promotions/truncations of symbolic integer values.

llvm-svn: 65480

decls. Test and document the semantic location of class template
specialization definitions that occur within a scope enclosing the
scope of the class template.

llvm-svn: 65478