that is in an anonymous namespace, give that function or variable
internal linkage.

This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:

  - Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
    when the declaration is in an anonymous namespace.
  - Added Type::getLinkage() to determine the linkage of a type, which
    is defined as the minimum linkage of the types (when we're dealing
    with a compound type that is not a struct/class/union).
  - Extended NamedDecl::getLinkage() to consider the linkage of the
    template arguments and template parameters of function template
    specializations and class template specializations.
  - Taught code generation to rely on NamedDecl::getLinkage() when
    determining the linkage of variables and functions, also
    considering the linkage of the types of those variables and
    functions (C++ only). Map UniqueExternalLinkage to internal
    linkage, taking out the explicit checks for
    isInAnonymousNamespace().

This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:

LLVM:
  Expected Passes    : 4006
  Expected Failures  : 32
  Unsupported Tests  : 40
  Unexpected Failures: 736

Clang:
  Expected Passes    : 1903
  Expected Failures  : 14
  Unexpected Failures: 75

Overall:
  Expected Passes    : 5909
  Expected Failures  : 46
  Unsupported Tests  : 40
  Unexpected Failures: 811

Still to do:
  - Improve testing
  - Check whether we should allow the presence of types with
  InternalLinkage (in addition to UniqueExternalLinkage) given
  variables/functions internal linkage in C++, as mentioned in
  PR5792. 
  - Determine how expensive the getLinkage() calls are in practice;
  consider caching the result in NamedDecl.
  - Assess the feasibility of Chris's idea in comment #1 of PR5792.

llvm-svn: 95216

llvm-svn: 95215

llvm-svn: 95214

initializer. Grrr....

llvm-svn: 95211

llvm-svn: 95203

llvm-svn: 95201

RegionStoreManager::InvalidateRegions() by adjusting the worklist to
iterate over BindingKeys instead of MemRegions.  We also only need to
do the actual invalidation work on base regions, and for non-base
regions just blow away their bindings.

llvm-svn: 95200

Implement Doug's suggestion. Eliminate the Stmts pointer from CXXTryStmt and instead allocate the statements after the object.

llvm-svn: 95199

 - Requires backend support, which only exists for i386--darwin currently.

No 'as' required:
--
ddunbar@ozzy:tmp$ cat t.c
int main() { return 42; }
ddunbar@ozzy:tmp$ clang -m32 -integrated-as t.c


ddunbar@ozzy:tmp$ ./a.out; echo $?
42
ddunbar@ozzy:tmp$
--

The random extra whitespace is how you know its working! :)

llvm-svn: 95194

not build a subregion map and instead do a single scan of the store.
This is done by building "region clusters" that represent the
collection of regions that have the same base region.  Invalidating
any region in a cluster means that they all should get invalidated.

This change brought out a point that Zhongxing mentioned to me
offline: the flattened memory binding has issues distinguishing
between direct and default bindings.  For example, setting the default
value for an entire struct is the same as binding to the first
element.  To address this problem, I moved the binding "tag" (Direct
or Default) from BindingVal to BdingKey (and removed BindingVal
entirely).  This requires us to do double lookups in some cases; and
there is still much more cleanup that can be done.

This change produced a noticeable speedup when analyzing sqlite3 (a
reduction of 4% in running time).

llvm-svn: 95193

realize that CXXConstructExpr is always implicit, so we should just
return its argument (if there is only one) rather than directly
invoking the constructor.

llvm-svn: 95192

llvm-svn: 95190

- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon.  This also simplifies the code generated by the GNU runtime a bit.  

- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.

- Recognise @selector() expressions as valid static initialisers (as GCC does).

- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants.  These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.

- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector.  This is needed for generating typed selectors from @selector() expressions (as GCC does).  Ideally, this information should be stored in the Selector, but that would be an invasive change.  We should eventually add checks for common uses of @selector() expressions.  Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:

- (id)performSelector: __attribute__((selector_types(id, SEL, id)))(SEL)
           withObject: (id)object;

Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature.  We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.

- Made @selector() expressions emit type info if available and the runtime supports it.

Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac.  This currently just assert()s.

llvm-svn: 95189

llvm-svn: 95188

llvm-svn: 95185

llvm-svn: 95182

appropriately.  Call out a few missing cases in the expression mangler.

llvm-svn: 95176

(per Doug's comment).

llvm-svn: 95169

lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:

  const int i;
  (void)(i + 17);

the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it. 

We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
  - the left-hand side of a '.' operator
  - the left-hand side of an assignment
  - a C++ throw expression
  - a subscript expression that's subscripting a vector

Making this change exposed two issues with blocks:
  - we were deducing const-qualified return types of non-class type
  from a block return, which doesn't fit well
  - we weren't always setting the known return type of a block when it
  was provided with the ^return-type syntax

Fixes the current Clang-on-Clang compile failure and PR6076.

llvm-svn: 95167

declaration. Fixes radar 7590273.

llvm-svn: 95164

Remove RegionStoreSubRegionMap::iterator and RegionStoreSubRegionMap::begin_end().  This is a precursor to using DenseSet to represent region sets instead of ImmutableSet.

llvm-svn: 95151

llvm-svn: 95128

llvm-svn: 95125

WHAT!?!

It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.

In this commit:
  - Enum types with a promotion type of "int" or "unsigned int" are
  promotable.
  - Tweaked the computation of promotable types for enums
  - For all of the ABIs, treat enum types the same way as their
  underlying types (*not* their promotion types) for argument passing
  and return values
  - Extend the ABI tester with support for enumeration types

llvm-svn: 95117

Set the correct vtable pointers _before_ generating code for any member initializers. Fixes about ~2000 clang/LLVM tests in the clang-on-clang build.

llvm-svn: 95116

llvm-svn: 95110

llvm-svn: 95108

llvm-svn: 95106

llvm-svn: 95104

Check for redefinitions in MergeVarDecl. This finds redefinitions of globals without an initializer in C++ and thus fixes PR5451.

llvm-svn: 95098

Fixes radar 7589414.

llvm-svn: 95097

llvm-svn: 95096

llvm-svn: 95095

type qualifiers and type specifiers in any order.   For example,
this is valid: struct x {...} typedef y;

This fixes PR6208.

llvm-svn: 95094

this is still a popular thing to do.

llvm-svn: 95093

unused variable warning.

llvm-svn: 95085

llvm-svn: 95079

magnitude clearer.

llvm-svn: 95078

Eliminates a lot of spurious global initializers, fixing PR6205.

llvm-svn: 95077

llvm-svn: 95076