- 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

llvm-svn: 55567

 - We are beyond the point where this shows up often and when it does
   generating miscompiled files is bad.

llvm-svn: 54836

 - Kill unnecessary #includes in .cpp files. This is an automatic
   sweep so some things removed are actually used, but happen to be
   included by a previous header. I tried to get rid of the obvious
   examples and this was the easiest way to trim the #includes in one
   fell swoop.
 - We now return to regularly scheduled development.

llvm-svn: 54632

 - Drop {Decl.h,DeclObjC.h,IdentifierTable.h} from Expr.h
 - Moved Sema::getCurMethodDecl() out of line (dependent on
   ObjCMethodDecl via dyn_cast).

llvm-svn: 54629

different address spaces) for llvm r54195.

llvm-svn: 54241

llvm-svn: 54049

llvm-svn: 53948

This subsumes Nico Weber's patch and implements bzero in terms
of llvm.memset to match llvm-gcc.

llvm-svn: 53888

This closes <rdar://problem/6080720>, support for __builtin_constant_p
has been filed separately.

llvm-svn: 53885

llvm-svn: 53878

llvm-svn: 53866

 + test case

llvm-svn: 53851