variables.
 - PR3657.

llvm-svn: 65381

  - When we are declaring a function in local scope, we can merge with
    a visible declaration from an outer scope if that declaration
    refers to an entity with linkage. This behavior now works in C++
    and properly ignores entities without linkage.
  - Diagnose the use of "static" on a function declaration in local
    scope.
  - Diagnose the declaration of a static function after a non-static
    declaration of the same function.
  - Propagate the storage specifier to a function declaration from a
    prior declaration (PR3425)
  - Don't name-mangle "main"

llvm-svn: 65360

llvm-svn: 65285

llvm-svn: 65256

llvm-svn: 65252

 - PR3629.

llvm-svn: 65203

system header.
 - Prevents a codegen crash when anything used anything in tgmath! :)

llvm-svn: 65200

 - PR3463 (again).

llvm-svn: 65133

 - Remove an unused variant of EmitCallExpr overload.

llvm-svn: 65130

llvm-svn: 65115

 - PR3463, PR3398, <rdar://problem/6553401> crash on relocatable
   symbol addresses as constants in static locals.

 - There are many more scenarious we could handle (like arithmetic on
   such an int) but this is the main use case.

llvm-svn: 65074

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

 - Renamed to getDeclAlignInBytes since most other query functions
   work in bits.

 - Fun to track down as isIntegerConstantExpr was getting it right,
   but Evaluate() was getting it wrong. Maybe we should assert they
   compute the same thing when they succeed?

llvm-svn: 64828

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

 - 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

prototype, synthesize ParmVarDecls for prototype-less FunctionDecl.

llvm-svn: 64666

llvm-svn: 64599

important for both keeping the generated LLVM simple and for ensuring
that integer types are passed/promoted correctly.

llvm-svn: 64529

missing-?:-true-value extension.

llvm-svn: 64505

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: 64502

 - 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

llvm-svn: 64445

llvm-svn: 64425

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: 64411

llvm-svn: 64380

llvm-svn: 64368

finishing off rdar://6520707

llvm-svn: 64295

llvm-svn: 64252

llvm-svn: 64195

ABI.

llvm-svn: 64187

llvm-svn: 64173

llvm-svn: 64168

llvm-svn: 63952

scalar/complex/aggregate cases.
 - Currently disabled for x86_64, triggering a misoptimization
   (PR3489).

llvm-svn: 63864