alloca without declaring it.

llvm-svn: 72719

llvm-svn: 72504

llvm-svn: 72446

llvm-svn: 72210

llvm-svn: 72033

llvm-svn: 72032

rdar://6880573

llvm-svn: 71637

rdar://6880573

llvm-svn: 71636

semantic rules that gcc and icc use.  This implements the variadic
and concrete versions as builtins and has sema do the 
disambiguation.  There are probably a bunch of details to finish up
but this seems like a large monotonic step forward :)

llvm-svn: 71212

llvm-svn: 70794

llvm-svn: 70145

llvm-svn: 69428

 - No functionality change.

llvm-svn: 68987

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

__sync_bool_compare_and_swap.
 - <rdar://problem/6762223> [sema/irgen] support
   __sync_bool_compare_and_swap and __sync_add_and_fetch

llvm-svn: 68482

 - Define pow[lf]?, sqrt[lf]? as builtins.

 - Add -fmath-errno option which binds to LangOptions.MathErrno

 - Add new builtin flag Builtin::Context::isConstWithoutErrno for
   functions which can be marked as const if errno isn't respected for
   math functions. Sema automatically marks these functions as const
   when they are defined, if MathErrno=0.

 - IRgen uses const attribute on sqrt and pow library functions to
   decide if it can use the llvm intrinsic.

llvm-svn: 64689

 - Fix test case to not only have negative tests.

llvm-svn: 64674

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

case on x86_64.

llvm-svn: 64333

Untested, Daniel or Nate please review.

llvm-svn: 63814

r63765).

llvm-svn: 63795

llvm-svn: 63773

__builtin___CFStringMakeConstantString.  (We get into trouble in 
GenerateStaticBlockVarDecl if the constant folder isn't accurate.)

llvm-svn: 62949

struct.

llvm-svn: 62585

va_list is a struct, like x86-64.

If anyone has a better idea for how to do the check in the if 
statements, suggestions are welcome.

llvm-svn: 62582

builtins.

Also, a minor tweak to va_copy for consistency.

llvm-svn: 62574

llvm-svn: 62458

llvm-svn: 61324

llvm-svn: 60321

llvm-svn: 59426

llvm-svn: 58680

va_list, not the value.  Patch fixes an assert on 
x86-64 and a wrong-code bug on x86.  I'm not completely sure, 
but I think it's a regression from r58306.

Does anyone run regression tests regularly on x86-64? The crash should 
have been picked up there.

llvm-svn: 58366

llvm-svn: 57563

llvm-svn: 57335

constant lvalue.  Implement this in codegen by moving the code out of CGBuiltin
into EmitConstantExpr.

llvm-svn: 57163

it is possible that a builtin could sometimes be folded (e.g. __builtin_clz)
if it's operand is a constant.

llvm-svn: 57161

llvm-svn: 57157

do it instead.  We should still handle __builtin_nan etc, but don't yet.
This fixes incorrect evaluation of __builtin_constant_p, a FIXME.

llvm-svn: 57156

llvm-svn: 56830

 - Currently CodeGen always returns a conservative value for this (-1
   or 0 depending on the context).

llvm-svn: 55735