llvm-svn: 102680

MachineFunction::DefaultDebugLoc.  We now use the same technique as
DwarfDebug::beginFunction to find the starting line number for a
function.

llvm-svn: 102679

easy cases.

llvm-svn: 102678

might not have been an insertion block set at start.  Fixes PR6975.

llvm-svn: 102677

llvm-svn: 102676

llvm-svn: 102674

entering the current instantiation.  Set up a little to preserve type location
information for typename types while we're in there.

Fixes a Boost failure.

llvm-svn: 102673

of different register classes. e.g.

  %reg1048:3<def> = EXTRACT_SUBREG %RAX<kill>, 3

Where %reg1048 is a GR32 register. This is not impossible to handle, but it is
pretty hard and very rare.

This should unbreak the dragonegg builder.

llvm-svn: 102672

llvm-svn: 102671

llvm-svn: 102670

llvm-svn: 102669

print randomly in debug output.

llvm-svn: 102668

llvm-svn: 102667

llvm-svn: 102666

are several known issues to address for it should be turned on by default.

llvm-svn: 102664

llvm-svn: 102663

llvm-svn: 102662

llvm-svn: 102661

llvm-svn: 102657

	##DEBUG_VALUE: runOnMachineFunction:this <- RDI+0
	##DEBUG_VALUE: runOnMachineFunction:fn <- RSI+0
	##DEBUG_VALUE: DeadDefs <- undef ## SimpleRegisterCoalescing.cpp:2706
	##DEBUG_VALUE: getRegInfo:this <- [%rsp+$56]+$0
	##DEBUG_VALUE: getTarget:this <- [%rsp+$56]+$0

llvm-svn: 102655

llvm-svn: 102654

llvm-svn: 102653

llvm-svn: 102652

llvm-svn: 102651

address of an overloaded function (or function template), perform that
resolution prior to determining the implicit conversion
sequence. This resolution is not part of the implicit conversion
sequence itself.

Previously, we would always consider this resolution to be a
function pointer decay, which was a lie: there might be an explicit &
in the expression, in which case decay should not occur. This caused
the CodeGen assertion in PR6973 (where we created a 
pointer to a pointer to a function when we should have had a pointer
to a function), but it's likely that there are corner cases of
overload resolution where this would have failed.

Cleaned up the code involved in determining the type that will
produced afer resolving the overloaded function reference, and added
an assertion to make sure the result is correct. Fixes PR6973.

llvm-svn: 102650

just leave it in Developer/usr/local/lib.

llvm-svn: 102646

categories. Issue usual warnings instead of
confusing error message. Radar 7920807

llvm-svn: 102645

llvm::GLobalVariable name may not match user visibile name for function static variables.

llvm-svn: 102644

Add USR support for 'static' functions and local variables, which can be handy for resolving named variables within a translation unit.

llvm-svn: 102641

they have no linkage and by definition are anonymous.

llvm-svn: 102640

llvm-svn: 102639

llvm-svn: 102638

llvm-svn: 102637

Do some minor refactoring along the way.

llvm-svn: 102635

for similar methods.  No functionality change.

llvm-svn: 102634

IRgen/NeXT: Put the synthesized _objc_super, _message_ref_t decls in a valid DeclContext, to satisfy the invariants that should hold on a RecordDecl.

llvm-svn: 102624

llvm-svn: 102623

instead of NDEBUG.

llvm-svn: 102622

llvm-svn: 102621

level metadata does not have any function local operands.
This would have caught the problem found in PR6112.

llvm-svn: 102620