over to VarDecl::isThisDeclarationADefinition(), which handles
variables declared with linkage specifications better (among other
things). CMake 2.9 (from CVS) now builds with clang++ and is somewhat
functional.

llvm-svn: 95486

Only append 'L' for internal variable declarations, not all declarations. (Found by the mangle checker, yay)

llvm-svn: 95485

llvm-svn: 95476

llvm-svn: 95474

crashing unceremoniously.

llvm-svn: 95464

taken for non-trivial constructors.

llvm-svn: 95457

follows (as conservatively as possible) gcc's current behavior:  attributes
written on return types that don't apply there are applied to the function
instead, etc.  Only parse CC attributes as type attributes, not as decl attributes;
don't accepet noreturn as a decl attribute on ValueDecls, either (it still
needs to apply to other decls, like blocks).  Consistently consume CC/noreturn
information throughout codegen;  enforce this by removing their default values
in CodeGenTypes::getFunctionInfo().

llvm-svn: 95436

llvm-svn: 95430

llvm-svn: 95427

llvm-svn: 95423

llvm-svn: 95416

(Fixes radar 7609722).

llvm-svn: 95406

conceptually correct. Review appreciated (Chris, Eli, Anders).

llvm-svn: 95401

llvm-svn: 95400

getting the calling convention from the target function, which may or may not
exist. Fixes PR5280.

llvm-svn: 95399

need to deal with aggregates specially; this is consistent with the rest of IRgen.

Also, simplify EmitParmDecl and don't worry about using Decl::getNameAsString.

llvm-svn: 95393

llvm-svn: 95389

llvm-svn: 95377

llvm-svn: 95375

If a global initializer has a non-trivial destructor it can't be emitted as a constant (even if it has a trivial constructor).

llvm-svn: 95363

Fixes latent and not-so-latent objc++ and blocks++ bugs.

llvm-svn: 95340

of a C++ record.  Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition.  Also cuts down on memory usage.

llvm-svn: 95330

With this fix, and the other fixes committed today a make check-all with a clang-built LLVM now gives:

Expected Passes    : 6933
Expected Failures  : 46
Unsupported Tests  : 40
Unexpected Failures: 27

which means that we pass 99.96% of all tests :) The resulting 27 tests are all LLVMC tests and seem to be because of differences in the clang and gcc drivers.

llvm-svn: 95313

Fix a bug where we would not mark temporaries as conditional when emitting a conditional operator as an lvalue.

llvm-svn: 95311

Rename StartConditionalBranch/FinishConditionalBranch to BeginConditionalBranch/EndConditionalBranch.

llvm-svn: 95308

Fix another pointer-to-member function miscompile, this time when trying to call a virtual member function.

llvm-svn: 95307

llvm-svn: 95305

llvm-svn: 95284

llvm-svn: 95275

float literals, and unresolved lookups (which required hand-wavey extensions).

llvm-svn: 95273

working code, for no apparent reason.

llvm-svn: 95244

llvm-svn: 95235

llvm-svn: 95232

llvm-svn: 95226

Revert the new reference binding code; I came up with a way simpler solution for the reference binding bug that is preventing self-hosting.

llvm-svn: 95223

First pass at adding GC support for GNU runtime.  GC ivar maps not yet constructed, GC flag not set.

Please don't try using this yet - the runtime support is still very immature and your code will almost certainly crash if you do.  

llvm-svn: 95222

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: 95201

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

- 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