block, if the function is supposed to return a value as we don't know
exactly what the asm code does.

llvm-svn: 91073

llvm-svn: 91072

this construct, but might as well for completeness.

llvm-svn: 91071

recently introduced crash.

llvm-svn: 91070

llvm-svn: 91069

(since we now parse all of the headers appropriately) and teaching
LLVM-Code-Syntax about the extra paths needed to parse the backends.

llvm-svn: 91068

llvm-svn: 91067

Surprisingly, we *do* diagnose one of them.  Since we don't really track scopes into
instantiation, this has to signal some kind of bug.

llvm-svn: 91063

llvm-svn: 91062

It's not safe to coalesce a move where src and dst registers have different subregister indices. e.g.:
%reg16404:1<def> = MOV8rr %reg16412:2<kill>

llvm-svn: 91061

llvm-svn: 91060

in objective-c++ mode.

llvm-svn: 91059

llvm-svn: 91058

declaration.  Rename note_using_decl to note_using, which is possibly less confusing.
Add a test for non-class-scope using decl collisions and be sure to note the case
we can't diagnose yet.

llvm-svn: 91057

into its own helper method. No change in functionality.

llvm-svn: 91056

Create global variable DIEs after creating subprogram DIEs. This allows function level static variable's to find their context at the time of DIE creation.

llvm-svn: 91055

llvm-svn: 91053

a type currently being defined, from Nicola Gigante!

llvm-svn: 91052

llvm-svn: 91051

llvm-svn: 91050

The coalescer is supposed to clean these up, but when setting up parameters
for a function call, there may be copies to physregs. If the defining
instruction has been LICM'ed far away, the coalescer won't touch it.

The register allocation hint does not always work - when the register
allocator is backtracking, it clears the hints.

This patch is more conservative than r90502, and does not break
483.xalancbmk/i686. It still breaks the PowerPC bootstrap, so it is disabled
by default, and can be enabled with the -trivial-coalesce-ends option.

llvm-svn: 91049

This code was crashing always with oprofile enabled, since it tried to create a StringRef
out of NULL, which run strlen on NULL.

llvm-svn: 91046

are a couple of O(n^2) operations in this, some analogous to the usual O(n^2)
redeclaration problem and some not.  In particular, retroactively removing
shadow declarations when they're hidden by later decls is pretty unfortunate.
I'm not yet convinced it's worse than the alternative, though.

llvm-svn: 91045

llvm-svn: 91044

llvm-svn: 91043

Mangle static variables inside Objective-C methods in Objective-C++. We currently mangle them the same way as gcc does.

llvm-svn: 91042

llvm-svn: 91041

a better diagnostic in the second example.

llvm-svn: 91040

llvm-svn: 91039

to use ColonProtectionRAIIObject in the C codepath even though it
won't matter for consistency.

llvm-svn: 91037

llvm-svn: 91036

during throw to deallocate the exception object.  WIP.

llvm-svn: 91035

llvm-svn: 91032

llvm-svn: 91027

llvm-svn: 91026

llvm-svn: 91025

llvm-svn: 91024

TODOs for other classes that could be moved out of Parser.h.  I don't plan
to do these in the near term though.

llvm-svn: 91023

llvm-svn: 91016

llvm-svn: 91015