Comment 4 for bug 721378

I see a very deep recursion in the C++ frontend instead which blows my stack.

#7701 0x000000000079ae0f in cp_genericize_r (stmt_p=0x7ffff5b81a98,
    walk_subtrees=0x7fffffffd100, data=0x7fffffffd4c0)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/cp-gimplify.c:1023
1023 cp_walk_tree (&BIND_EXPR_BODY (stmt),
(gdb)
#7700 0x0000000000f00a6d in walk_tree_1 (tp=0x7ffff48ba630,
    func=0x7985ba <cp_genericize_r>, data=0x7fffffffd4c0, pset=0x0,
    lh=0x731537 <cp_walk_subtrees>)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/tree.c:10386
10386 WALK_SUBTREE (*tsi_stmt_ptr (i));
(gdb)
#7699 0x0000000000f022f9 in walk_tree_1 (tp=0x7ffff59c38f8,
    func=0x7985ba <cp_genericize_r>, data=0x7fffffffd4c0, pset=0x0,
    lh=0x731537 <cp_walk_subtrees>)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/tree.c:10529
10529 /* Go through the subtrees. We need to do this in forward order so
(gdb)
#7698 0x0000000000f00a6d in walk_tree_1 (tp=0x7ffff7ff2178,
    func=0x7985ba <cp_genericize_r>, data=0x7fffffffd4c0, pset=0x0,
    lh=0x731537 <cp_walk_subtrees>)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/tree.c:10386
10386 WALK_SUBTREE (*tsi_stmt_ptr (i));
....

they are all TRY_CATCH_EXPRs. Gimplification will probably run into
similar recursion issues.

I can't reproduce the isssue with an unlimited stack with release
checking compiled FSF 4.6.1 or 4.5.3 releases.

For some reason the C++ compiler nests constructing the members:

;; Function Container::Container() (null)
;; enabled by -tree-original

{
  <<cleanup_point <<< Unknown tree: expr_stmt
  Child::Child (&((struct Container *) this)->s_20pm) >>>>>;
  try
    {
      <<cleanup_point <<< Unknown tree: expr_stmt
  Child::Child (&((struct Container *) this)->s_20zTohl) >>>>>;
      try
        {
          <<cleanup_point <<< Unknown tree: expr_stmt
  Child::Child (&((struct Container *) this)->s_20zToRB) >>>>>;
          try
            {

Jason, can't we do something more optimal here?