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

llvm-svn: 64452

llvm-svn: 64451

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

llvm-svn: 64387

llvm-svn: 64380

llvm-svn: 63952

 - Emits all declarations, even unused (static) ones.
 - Useful when doing minimization of codegen problems (otherwise
   problems localized to a static function aren't minimized well).

llvm-svn: 63776

 - Inefficient & leaks memory currently, will be cleaned up subsequently.

llvm-svn: 63567

 - Lift CGFunctionInfo creation above ReturnTypeUsesSret and
   EmitFunction{Epi,Pro}log.

llvm-svn: 63553

function/call info.

llvm-svn: 63466

for the new meta-data.

llvm-svn: 62806

the new ObjC's abi.

llvm-svn: 62721

"logical" location, refer to the "instantiation" location.

llvm-svn: 62316

llvm-svn: 62139

gen issue fix.

llvm-svn: 61901

llvm-svn: 61747

When emitting the static variables we need to make sure that the order is preserved. 
Fix this by making StaticDecls a std::list which has O(1) random removal.

llvm-svn: 61621

Patch by Ilya Okonsky

llvm-svn: 61437

and separates lexical name lookup from qualified name lookup. In
particular:
  * Make DeclContext the central data structure for storing and
    looking up declarations within existing declarations, e.g., members
    of structs/unions/classes, enumerators in C++0x enums, members of
    C++ namespaces, and (later) members of Objective-C
    interfaces/implementations. DeclContext uses a lazily-constructed
    data structure optimized for fast lookup (array for small contexts,
    hash table for larger contexts). 

  * Implement C++ qualified name lookup in terms of lookup into
    DeclContext.

  * Implement C++ unqualified name lookup in terms of
    qualified+unqualified name lookup (since unqualified lookup is not
    purely lexical in C++!)

  * Limit the use of the chains of declarations stored in
    IdentifierInfo to those names declared lexically.

  * Eliminate CXXFieldDecl, collapsing its behavior into
    FieldDecl. (FieldDecl is now a ScopedDecl).

  * Make RecordDecl into a DeclContext and eliminates its
    Members/NumMembers fields (since one can just iterate through the
    DeclContext to get the fields).

llvm-svn: 60878

the synthesis is in an implementation of s subclass of
a super class where the property has been declared.

llvm-svn: 60792

llvm-svn: 60778