This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/49756] g++ ICE
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 18 Jul 2011 09:17:01 +0000
- Subject: [Bug c++/49756] g++ ICE
- Auto-submitted: auto-generated
- References: <bug-49756-4@http.gcc.gnu.org/bugzilla/>
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?