This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/49756] g++ ICE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49756

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.07.18 09:16:59
                 CC|                            |jason at gcc dot gnu.org
          Component|tree-optimization           |c++
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-07-18 09:16:59 UTC ---
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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]