speeding up the testcase in PR3810 by 60%.

llvm-svn: 67431

 - PR3818.

llvm-svn: 67297

whose sema decl is at the translation unit.

llvm-svn: 67249

llvm-svn: 66691

llvm-svn: 66652

module symbol table. The root problem inspiring this was fixed in
r66316 (and again in r66506).

llvm-svn: 66512

reuse the prior one.

llvm-svn: 66408

This is a bit cleaner, and also "fixes" bad code that compares the 
addresses of the string constants.

llvm-svn: 66346

correct, but an extra set of ObjC eyes would be good.

llvm-svn: 66342

CodeGenModule::CreateRuntimeVariable.

 - No real functionality change; although we now assert on silly
   things like:
--
int objc_exception_throw;
void f0() { @throw(@"A"); }
--
   instead of accepting it.

llvm-svn: 66292

 - <rdar://problem/6652110> clang should support weak_import

llvm-svn: 66270

 - 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

return/argument types.  (The generated IR isn't ideal, but we can't 
really do better in general.)

llvm-svn: 66132

llvm-svn: 66046

BlockModule.  No functionality change.  This should help people that
don't want to know anything about blocks not be confused by the
overloaded use of the term block or nor want to see all the blocks
goop.

llvm-svn: 66042

 - PR3698.

llvm-svn: 66038

llvm-svn: 65806

llvm-svn: 65782

llvm-svn: 65749

we ensure that things added to the module can be found even when they
are not in GlobalDeclMap.  The later is for increased flexibility,
should someone want to do something tricky like extern "Ada" in the
same module.

llvm-svn: 65657

llvm-svn: 65611

llvm-svn: 65582

The big difference here is that (like string literal) @encode has 
array type, not pointer type.

llvm-svn: 65391

 - PR3629.

llvm-svn: 65203

error, so we don't crash.

llvm-svn: 65099

llvm-svn: 65056

 - <rdar://problem/6584606> clang/x86-64 - too many reg saves

llvm-svn: 65032

situation where a tentative decl was emitted *after* the actual
initialization. This occurs in some rare situations with static decls.
 - PR3613.

 - I'm not particularly happy with this fix, but I don't see a simpler
   or more elegant solution yet.

llvm-svn: 65018

llvm-svn: 64984

llvm-svn: 64969

llvm-svn: 64944

we can define builtins such as fprintf, vfprintf, and
__builtin___fprintf_chk. Give a nice error message when we need to
implicitly declare a function like fprintf.

llvm-svn: 64526

etc.) when we perform name lookup on them. This ensures that we
produce the correct signature for these functions, which has two
practical impacts:

  1) When we're supporting the "implicit function declaration" feature
  of C99, these functions will be implicitly declared with the right
  signature rather than as a function returning "int" with no
  prototype. See PR3541 for the reason why this is important (hint:
  GCC always predeclares these functions).
 
  2) If users attempt to redeclare one of these library functions with
  an incompatible signature, we produce a hard error.

This patch does a little bit of work to give reasonable error
messages. For example, when we hit case #1 we complain that we're
implicitly declaring this function with a specific signature, and then
we give a note that asks the user to include the appropriate header
(e.g., "please include <stdlib.h> or explicitly declare 'malloc'"). In
case #2, we show the type of the implicit builtin that was incorrectly
declared, so the user can see the problem. We could do better here:
for example, when displaying this latter error message we say
something like:

  'strcpy' was implicitly declared here with type 'char *(char *, char
  const *)'

but we should really print out a fake code line showing the
declaration, like this:

  'strcpy' was implicitly declared here as:

    char *strcpy(char *, char const *)

This would also be good for printing built-in candidates with C++
operator overloading.

The set of C library functions supported by this patch includes all
functions from the C99 specification's <stdlib.h> and <string.h> that
(a) are predefined by GCC and (b) have signatures that could cause
codegen issues if they are treated as functions with no prototype
returning and int. Future work could extend this set of functions to
other C library functions that we know about.

llvm-svn: 64504

llvm-svn: 64500

 - PR3566

llvm-svn: 64492

 - Fix emission of static functions with constructor attribute while I
   was here.
<rdar://problem/6140899> [codegen] "static" and attribute-constructor interact poorly

llvm-svn: 64488

for attribute used support.  
- No functionality change.

llvm-svn: 64487

llvm-svn: 64486

llvm-svn: 64481

llvm-svn: 64473