llvm-svn: 118238

llvm-svn: 118236

llvm-svn: 118172

visibility of their function.

llvm-svn: 118065

// rdar: //8620510 and PR7666

llvm-svn: 118019

llvm-svn: 117928

Rename getBaseClassOffset to getBaseClassOffsetInBits and introduce a getBaseClassOffset which returns the offset in CharUnits. Do the same thing for getVBaseClassOffset.

llvm-svn: 117881

independently of whether they're definitions, then teach IR generation to
ignore non-explicit visibility when emitting declarations.  Use this to
make sure that RTTI, vtables, and VTTs get the right visibility.

More of rdar://problem/8613093

llvm-svn: 117781

in asm's.  PR 8501, 8602988.
I don't like including Type.h where it is; the idea was
to get references to X86_MMXTy out of the common code.
Maybe there's a better way?

llvm-svn: 117736

llvm-svn: 117734

for namespace-scope variable declarations.

Apply visibility in IR gen to variables that are merely declared
and never defined.  We were previously emitting these with default
visibility unless they were declared with private_extern.

Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.

llvm-svn: 117729

This is tested by funcargs.exp in gdb testsuite.

llvm-svn: 117659

declared", it breaks things.

llvm-svn: 117653

anyone has ever intentionally done this outside of a compiler test case.

llvm-svn: 117645

and never defined.  We were previously emitting these with default
visibility unless they were declared with private_extern.

Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.

llvm-svn: 117644

llvm-svn: 117613

using the memory type;  fixes an assert.

Fixes rdar://problem/8605032

llvm-svn: 117610

llvm-svn: 117576

llvm-svn: 117561

in the scope checker.  With that done, turn an indirect goto into a
protected scope into a hard error;  otherwise IR generation has to start
worrying about declarations not dominating their scopes, as exemplified
in PR8473.

If this really affects anyone, I can probably adjust this to only hard-error
on possible indirect gotos into VLA scopes rather than arbitrary scopes.
But we'll see how people cope with the aggressive change on the marginal
feature.

llvm-svn: 117539

Radar 8595129

llvm-svn: 117507

aggressive about the form we expect bools to be in.  I don't really have
time to fix all the sources right now.

llvm-svn: 117486

llvm-svn: 117456

on if its linkage is weak. Currently this is the
case but may change in the future. (part of radar 
8562966).

llvm-svn: 117452

llvm-svn: 117445

llvm-svn: 117444

of static data member of a class template.
Fixes //rdar :// 8562966 and pr8409.

llvm-svn: 117410

in IR gen, and use those to fix a correctness issue with bool atomic
intrinsics.  rdar://problem/8461234

llvm-svn: 117403

so that it's done in one place.

llvm-svn: 117386

llvm-svn: 117328

llvm-svn: 117321

they can be used outside of the main getTBAAInfo function.

llvm-svn: 117320

the patch. 

llvm-svn: 117159

more closely parallel the computation of linkage.  This gets us to a state
much closer to what gcc emits, modulo bugs, which will undoubtedly arise in
abundance.

llvm-svn: 117147

statement expressions, //rdar: //8540501

llvm-svn: 117146

Delay record type's debug info emission, in -flimit-debug-info mode, if member expression's base is call expr.

llvm-svn: 117127

llvm-svn: 117120

Tidy up MIPS_linkage name. Provide it only if it does not match regular name, otherwise it confuses debugger.
This is tested by local.C in llvmgcc testsuite.

llvm-svn: 117107

llvm-svn: 117106

llvm-svn: 117046