llvm-svn: 57180

llvm-svn: 57179

This is how this kind of initializers appear in the AST:
-The Init expression of the VarDecl is a functional type construction (of the VarDecl's type).
-The new VarDecl::hasCXXDirectInitializer() returns true.

e.g, for "int x(1);":
-VarDecl 'x' has Init with expression "int(1)" (CXXFunctionalCastExpr).
-hasCXXDirectInitializer() of VarDecl 'x' returns true.

A major benefit is that clients that don't particularly care about which exactly form was the initializer can handle both cases without special case code.
Note that codegening works now for "int x(1);" without any changes to CodeGen.

llvm-svn: 57178

This includes not marking a GEP involving a vector as unsafe, but only when it
has all zero indices. This allows scalarrepl to work in a few more cases.

llvm-svn: 57177

llvm-svn: 57176

Before there were two problems: (1) configure
turned "obj-c++" into "obj" in the langs line;
(2) the dejagnu library called it objc++ not
obj-c++.
Now the problem is that some of these tests don't
pass!

llvm-svn: 57167

readnone.  Make clearer that readnone functions do not
dereference pointer arguments.  Do not use the highly
ambiguous "side-effects" in the readonly description
(since such functions can have control flow side-effects,
such as throwing an exception, or looping for ever).

llvm-svn: 57166

llvm-svn: 57165

won't expand to the builtin.  This fixes rdar://6248329

llvm-svn: 57164

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

llvm-svn: 57163

llvm-svn: 57162

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

llvm-svn: 57161

depend on the value of this flag, it should depend on whether 
tryEvaluate is able to *actually* fold a builtin.

llvm-svn: 57160

which is checking for something that can be inconsistent with
what we can constant fold.

llvm-svn: 57159

interface into the constant folding interface.

llvm-svn: 57158

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

constants for them, just use the constant evaluator to do the job.  This
also fixes crashes on 'unknown constant builtins'.

llvm-svn: 57155

llvm-svn: 57154

condition as a constant even if the unevaluated side is a not a constant.
We don't do this when extensions are off, and we emit a warning when this 
happens:

t.c:22:11: warning: expression is not a constant, but is accepted as one by GNU extensions
short t = __builtin_constant_p(5353) ? 42 : somefunc();
          ^                                 ~~~~~~~~~~

suggestions for improvement are welcome.  This is obviously horrible, but
is required for real-world code.

llvm-svn: 57153

__builtin_constant_p properly, and add some scaffolding for
FloatExprEvaluator to eventually handle huge_val and inf.

llvm-svn: 57152

code.

llvm-svn: 57151

llvm-svn: 57150

llvm-svn: 57149

llvm-svn: 57148

llvm-svn: 57147

llvm-svn: 57146

llvm-svn: 57145

llvm-svn: 57144

llvm-svn: 57143

llvm-svn: 57142

llvm-svn: 57141

llvm-svn: 57140

target indep code.

llvm-svn: 57139

llvm-svn: 57138

llvm-svn: 57137

No funcitonality change.

llvm-svn: 57136

llvm-svn: 57135

llvm-svn: 57134

gcc).

llvm-svn: 57133