ABI conforming.

llvm-svn: 97702

llvm-svn: 97700

'%t' file was left around on my disk.  doh.

llvm-svn: 97699

some builtins will rely on target knowledge.

llvm-svn: 97693

llvm-svn: 97686

llvm-svn: 97679

llvm-svn: 97677

nested-name-specifier. For example, this allows member access in
diamond-shaped hierarchies like:

  struct Base {
    void Foo();
    int Member;
  };

  struct D1 : public Base {};
  struct D2 : public Base {};

  struct Derived : public D1, public D2 { }

  void Test(Derived d) {
    d.Member = 17; // error: ambiguous cast from Derived to Base
    d.D1::Member = 17; // error: okay, modify D1's Base's Member
  }

Fixes PR5820 and <rdar://problem/7535045>. Also, eliminate some
redundancy between Sema::PerformObjectMemberConversion() and
Sema::PerformObjectArgumentInitialization() -- the latter now calls
the former.

llvm-svn: 97674

((id)cat)->isa. Fixes radar 7709015.

llvm-svn: 97672

XFAIL and already tracked in bugzilla.

llvm-svn: 97671

llvm-svn: 97669

Add in c header path for various linuxes as well.

Partial patch from Christian Adåker!

llvm-svn: 97666

fix a code gen crash. This is WIP as not
all ABI cases are covered (there is a FIXME to 
this effect). Fixes radar 7696748.

llvm-svn: 97658

llvm-svn: 97656

llvm-svn: 97654

why the front-end is calculating the argument to llvm.eh.dwarf.cfa().

llvm-svn: 97653

to test clang_getCursorLinkage()

llvm-svn: 97648

llvm-svn: 97647

underlying linkage for the entity referred to by a
CXCursor.

llvm-svn: 97646

llvm-svn: 97643

llvm-svn: 97641

that are hidden by other derived base subobjects reached along a
lookup path that does *not* pass through the hiding subobject (C++
[class.member.lookup]p6). Fixes PR6462.

llvm-svn: 97640

__builtin_frob_return_address.  The implementations for both are
still trivial in the default case.

llvm-svn: 97638

for the base destructor, because aliases to declarations aren't legal.

Fixes PR 6471.

llvm-svn: 97637

level. No functionality change, and it obeys access control this
time.

llvm-svn: 97634

llvm-svn: 97625

If an initializer in a DeclStmt references the declared variable, that
extends the liveness of that variable.

llvm-svn: 97624

llvm-svn: 97621

(even if it is defined).  This fixes the issue of this function
returning '0' when SVN_VERSION is defined to be "".

Fixes: <rdar://problem/7663667>
llvm-svn: 97620

llvm-svn: 97619

static function. No functionality change.

llvm-svn: 97618

llvm-svn: 97615

llvm-svn: 97613

come back to bite us at some point. 

llvm-svn: 97607

declarations after the member has been explicitly specialized.  We already
did this after explicit instantiation definitions;  not doing it for
declarations meant that subsequent definitions would see a previous
member declaration with specialization kind "explicit instantiation decl",
which would then happily get overridden.

Fixes PR 6458.

llvm-svn: 97605

After discussion with Zhongxing, don't force the initializer of DeclStmts to be
block-level expressions.

This led to some interesting fallout:

[UninitializedValues]

Always visit the initializer of DeclStmts (do not assume they are block-level expressions).

[BasicStore]

With initializers of DeclStmts no longer block-level expressions, this causes self-referencing initializers (e.g. 'int x = x') to no longer cause the initialized variable to be live before the DeclStmt.  While this is correct, it caused BasicStore::RemoveDeadBindings() to prune off the values of these variables from the initial store (where they are set to uninitialized).  The fix is to back-port some (and only some) of the lazy-binding logic from RegionStore to
BasicStore.  Now the default values of local variables are determined lazily as opposed
to explicitly initialized.

llvm-svn: 97591

llvm-svn: 97590

we need to synthesize has been marked as used by Sema.

Change Sema to avoid these asserts.

llvm-svn: 97589

GCC. Fixes PR6301.

llvm-svn: 97579

llvm-svn: 97575