| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Decl*. This hopefully will obviate any concerns with violating strict type-aliasing issues.
llvm-svn: 57213
|
|
|
|
|
|
| |
rewriting Objective-c foreach statements.
llvm-svn: 57212
|
|
|
|
|
|
| |
Fixes build failure when target is i386.
llvm-svn: 57211
|
|
|
|
| |
llvm-svn: 57210
|
|
|
|
|
|
| |
processing the Decl of an Objective-C foreach statement.
llvm-svn: 57209
|
|
|
|
|
|
| |
processing the Decl of a @catch statement.
llvm-svn: 57208
|
|
|
|
|
|
| |
statement has a DeclStmt with a single Decl. Afterwards, use DeclStmt::getSolitaryDecl() to access that Decl (thus avoiding an assertion being triggered). These changes remove an unneeded use of ScopedDecl::getNextDeclarator() and DeclStmt::getDecl().
llvm-svn: 57207
|
|
|
|
|
|
| |
ScopedDecl chain.
llvm-svn: 57206
|
|
|
|
|
|
| |
This patch precedes removing getDecl() DeclStmt::entirely.
llvm-svn: 57205
|
|
|
|
| |
llvm-svn: 57204
|
|
|
|
|
|
| |
it is too aggressive.
llvm-svn: 57203
|
|
|
|
|
|
| |
Patch By Matthijs Kooijman.
llvm-svn: 57202
|
|
|
|
|
|
| |
unsigned and signed" warning (potential integer overflow).
llvm-svn: 57201
|
|
|
|
| |
llvm-svn: 57200
|
|
|
|
| |
llvm-svn: 57198
|
|
|
|
| |
llvm-svn: 57197
|
|
|
|
|
|
| |
of using DeclStmt::getDecl().
llvm-svn: 57196
|
|
|
|
|
|
|
| |
in a DeclStmt instead of using getDecl() to fetch the first Decl.
Steve: Please review this patch. 'make test' passes, and my cursory scan of the rewriter leads me to believe this doesn't break anything, but I'm not sure.
llvm-svn: 57195
|
|
|
|
|
|
| |
the first decl using the DeclStmt::decl_iterator.
llvm-svn: 57194
|
|
|
|
| |
llvm-svn: 57193
|
|
|
|
|
|
| |
scoped decl chain.
llvm-svn: 57192
|
|
|
|
|
|
| |
using PrintRawDecl (which falsely assumes DeclStmts have only one Decl).
llvm-svn: 57191
|
|
|
|
|
|
| |
soon be removed).
llvm-svn: 57190
|
|
|
|
|
|
|
|
| |
DeclStmts will wrap group of Decls.
Added FIXME.
llvm-svn: 57189
|
|
|
|
|
|
|
|
| |
class types.
Add a FIXME until class constructors are supported.
llvm-svn: 57188
|
|
|
|
|
|
| |
will soon be removed).
llvm-svn: 57187
|
|
|
|
| |
llvm-svn: 57186
|
|
|
|
|
|
| |
Improve description of unsupported formats.
llvm-svn: 57185
|
|
|
|
|
|
| |
optimized for size. Set OptForSize for each function separately.
llvm-svn: 57182
|
|
|
|
|
|
| |
ENABLE_EXPENSIVE_CHECKS for finding this.
llvm-svn: 57181
|
|
|
|
| |
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
|