subsequently crashed).

llvm-svn: 69567

llvm-svn: 69545

 - Exposed quite a few Sema issues and a CodeGen crash.

 - See FIXMEs in test case, and in SemaDecl.cpp (PR3983).

I'm skeptical that __private_extern__ should actually be a storage
class value. I think that __private_extern__ basically amounts to
  extern A __attribute__((visibility("hidden")))
and would be better off handled (a) as that, or (b) with an extra bit
in the VarDecl.

llvm-svn: 69020

 - No functionality change.

llvm-svn: 68987

llvm-svn: 68756

llvm-svn: 68755

Add a destination type argument to EmitConstantExpr. This will be used for when the destination has a reference type. (No functionality change yet)

llvm-svn: 68593

Don't use static globals for params as it confuses the optimzer that their values are never being used in the function.

llvm-svn: 68328

llvm-svn: 68280

declaration. Reject it.

llvm-svn: 68058

build.  This shaves another 3% off.

llvm-svn: 67460

in release-assert builds.  For automatic variables, explicitly set
a name with setName that does not make a temporary std::string.

This speeds up -emit-llvm-only -disable-free on PR3810 by 4.6%

llvm-svn: 67459

copy_helpers and dispose_helpers as necessary for them.

llvm-svn: 67453

llvm-svn: 67406

llvm-svn: 66343

llvm-svn: 66322

llvm-svn: 66257

llvm-svn: 66247

llvm-svn: 66243

llvm-svn: 66241

llvm-svn: 66231

 - For one thing, this adds unneeded overhead; for another, this
   routine can be used to emit unnamed decls which we shouldn't try to
   mangle.

llvm-svn: 66212

llvm-svn: 66159

llvm-svn: 66126

llvm-svn: 66117

booleans.

llvm-svn: 66012

llvm-svn: 66010

still give an unsupported error for them due to the fact this is a
work in progress.

llvm-svn: 66007

llvm-svn: 65688

 - PR3662.

llvm-svn: 65472

 - No functionality change.

llvm-svn: 65470

global variable) out of GenerateStaticBlockVarDecl. 
 - No intended functionality change.
 - Prep for some mild cleanups and PR3662.

llvm-svn: 65466

CodeGen.  I'm not sure whether this actually makes any visible 
difference, but it's better to be consistent anyway.

llvm-svn: 65259

llvm-svn: 65089

llvm-svn: 64984

IRgen no longer relies on isConstantInitializer, instead we just try
to emit the constant. If that fails then in C we emit an error
unsupported (this occurs when Sema accepted something that it doesn't
know how to fold, and IRgen doesn't know how to emit) and in C++ we
emit a guarded initializer.

This ends up handling a few more cases, because IRgen was actually
able to emit some of the constants Sema accepts but can't Evaluate().
For example, PR3398.

llvm-svn: 64780

llvm-svn: 64502

 - PR3566

llvm-svn: 64492

llvm-svn: 64445

ABI to the CodeGen library. Since C++ code-generation is so
incomplete, we can't exercise much of this mangling code. However, a
few smoke tests show that it's doing the same thing as GCC. When C++
codegen matures, we'll extend the ABI tester to verify name-mangling
as well, and complete the implementation here.

At this point, the major client of name mangling is in the uses of the
new "overloadable" attribute in C, which allows overloading. Any
"overloadable" function in C (or in an extern "C" block in C++) will
be mangled the same way that the corresponding C++ function would be
mangled.

llvm-svn: 64413