aboutsummaryrefslogtreecommitdiff
path: root/test/CodeGenCXX/condition.cpp
AgeCommit message (Collapse)Author
2010-07-23Revise cleanup IR generation to fix a major bug with cleanups (PR7686)John McCall
as well as some significant asymptotic inefficiencies with threading multiple jumps through deep cleanups. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109274 91177308-0d34-0410-b5e6-96231b3b80d8
2010-07-13Teach IR generation how to lazily emit cleanups. This has a lot of advantages,John McCall
mostly in avoiding unnecessary work at compile time but also in producing more sensible block orderings. Move the destructor cleanups for local variables over to use lazy cleanups. Eventually all cleanups will do this; for now we have some awkward code duplication. Tell IR generation just to never produce landing pads in -fno-exceptions. This is a much more comprehensive solution to a problem which previously was half-solved by checks in most cleanup-generation spots. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108270 91177308-0d34-0410-b5e6-96231b3b80d8
2010-07-06Stop testing for specific basic block numbers in this test.John McCall
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107632 91177308-0d34-0410-b5e6-96231b3b80d8
2010-07-06Validated by nightly-test runs on x86 and x86-64 darwin, including afterJohn McCall
self-host. Hopefully these results hold up on different platforms. I tried to keep the GNU ObjC runtime happy, but it's hard for me to test. Reimplement how clang generates IR for exceptions. Instead of creating new invoke destinations which sequentially chain to the previous destination, push a more semantic representation of *why* we need the cleanup/catch/filter behavior, then collect that information into a single landing pad upon request. Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional control flow) are generated, since it's actually fairly closely tied in with the former. Remove the need to track which cleanup scope a block is associated with. Document a lot of previously poorly-understood (by me, at least) behavior. The new framework implements the Horrible Hack (tm), which requires every landing pad to have a catch-all so that inlining will work. Clang no longer requires the Horrible Hack just to make exceptions flow correctly within a function, however. The HH is an unfortunate requirement of LLVM's EH IR. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107631 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-08When instantiating statements that involve conditions (if, while, do,Douglas Gregor
for, and switch), be careful to construct the full expressions as soon as we perform template instantation, so we don't either forget to call temporary destructors or destroy temporaries at the wrong time. This is the template-instantiation analogue to r103187, during which I hadn't realized that the issue would affect the handling of these constructs differently inside and outside of templates. Fixes a regression in Boost.Function. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103357 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-08Fix test for Release-Asserts buildDouglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103337 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-06Rework our handling of temporary objects within the conditions ofDouglas Gregor
if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103187 91177308-0d34-0410-b5e6-96231b3b80d8
2010-02-09Update tests in -Asserts mode. These tests really need to be rewritten...Daniel Dunbar
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95658 91177308-0d34-0410-b5e6-96231b3b80d8
2010-01-13Fix for Release-Asserts.Mike Stump
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93347 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-15Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar
- This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-25Implement proper cleanup semantics for condition variables in forDouglas Gregor
statements, e.g., for(; X x = X(); ) { ... } Daniel or Anders, please review! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89832 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-25Tweak the code-generation-for-condition-variables test case to get to what ↵Douglas Gregor
we want to test git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89818 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-25Eliminate CXXConditionDeclExpr with extreme prejudice.Douglas Gregor
All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89817 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-24Clean up the AST for while loops and fix several problems withDouglas Gregor
cleanups for while loops: 1) Make sure that we destroy the condition variable of a while statement each time through the loop for, e.g., while (shared_ptr<WorkInt> p = getWorkItem()) { // ... } 2) Make sure that we always enter a new cleanup scope for the body of the while loop, even when there is no compound expression, e.g., while (blah) RAIIObject raii(blah+1); git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89800 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-24Explicitly store the condition variable within switch statements, andDouglas Gregor
make sure that this variable is destroyed when we exit the switch statement. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89776 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-24Introduce cleanup scopes for "if" statements in two places:Douglas Gregor
- Outside the "if", to ensure that we destroy the condition variable at the end of the "if" statement rather than at the end of the block containing the "if" statement. - Inside the "then" and "else" branches, so that we emit then- or else-local cleanups at the end of the corresponding block when the block is not a compound statement. To make adding these new cleanup scopes easier (and since switch/do/while will all need the same treatment), added the CleanupScope RAII object to introduce a new cleanup scope and make sure it gets cleaned up. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89773 91177308-0d34-0410-b5e6-96231b3b80d8