Fix a bug which triggered the assertion I added yesterday. Basically, when we initialize the vtable pointer for a virtual base, and there was another path from the most derived class to another base with the same class type, we would use the wrong base.

llvm-svn: 101911

llvm-svn: 101909

@encode expression. 

llvm-svn: 101907

we will print with each error that occurs during template
instantiation. When the backtrace is longer than that, we will print
N/2 of the innermost backtrace entries and N/2 of the outermost
backtrace entries, then skip the middle entries with a note such as:

  note: suppressed 2 template instantiation contexts; use
  -ftemplate-backtrace-limit=N to change the number of template
  instantiation entries shown

This should eliminate some excessively long backtraces that aren't
providing any value.

llvm-svn: 101882

This mirror's Dan's patch for llvm-gcc in r97989, and
fixes the miscompilation in PR6525.  There is some contention
over whether this is the right thing to do, but it is the
conservative answer and demonstrably fixes a miscompilation.

llvm-svn: 101877

llvm-svn: 101876

llvm-svn: 101872

llvm-svn: 101871

Assert that the path from the derived to the base class in CodeGenFunction::GetAddressOfBaseClass is not ambiguous.

llvm-svn: 101869

llvm-svn: 101867

of buildbots with:

error: 'error' diagnostics expected but not seen: 
  Line 9: too few elements in vector initialization (expected 8 elements, have 2)
1 warning and 1 error generated.

llvm-svn: 101864

llvm-svn: 101863

llvm-svn: 101862

actual delete expressions, not just new expressions.

llvm-svn: 101861

llvm-svn: 101859

associated with a new expression if -fno-exceptions is set.

llvm-svn: 101841

will already have done so when the template is declared.

llvm-svn: 101838

function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.

llvm-svn: 101826

Only suppress the "extern variable has an initializer" warning when the extern entity being initialized is const.

llvm-svn: 101821

since it makes sense there to have const extern variables. Fixes
PR6495.

llvm-svn: 101818

llvm-svn: 101815

llvm-svn: 101814

Zhanyong Wan!

llvm-svn: 101813

fails to find anything,  perform ivar lookup and, if we find one,
consider this an instance message.

llvm-svn: 101810

(related to radar 7866951).

llvm-svn: 101799

Update all of the testcases accordingly.

llvm-svn: 101795

(related to PR6769).

llvm-svn: 101794

look from an Objective-C class or category to its implementation, to
pick up synthesized ivars. Fixes a problem reported by David
Chisnall.

llvm-svn: 101792

in for pre-snowleoprd (NeXt runtime). Fixes
radar 7866951

llvm-svn: 101791

llvm-svn: 101787

llvm-svn: 101786

llvm-svn: 101772

llvm-svn: 101771

llvm-svn: 101759

llvm-svn: 101758

If a method is virtual and the class key function is in another file, emit the method as available_externally.
Fixes PR6747

llvm-svn: 101757

as they are accessible in static methods in a class
local to the same function. Fixes PR6769.

llvm-svn: 101756

as a side-effect, remove two FIXMEs now fixed

llvm-svn: 101726

instantiating class members as part of an explicit
instantiation. Addresses a compilation problem in
Boost.Serialization.

llvm-svn: 101725

a qualified name. We weren't checking for an empty
nested-name-specifier when dealing with friend class templates
(although we were checking in the other places where we deal with this
paragraph). Fixes a Boost.Serialization showstopper.

llvm-svn: 101724