[Bug tree-optimization/49756] New: g++ ICE

[Bug tree-optimization/49756] New: g++ ICE

[doko at ubuntu dot com]

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

           Summary: g++ ICE
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: doko@ubuntu.com


Created attachment 24773
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24773
preprocessed source

[forwarded from http://launchpad.net/bugs/721378]

might related to PR48766, although I don't see the recursion in
fold_binary_loc(). seen with current 4.4, 4.5, 4.6 branches and trunk.

$ g++ -c testcase.ii 
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.

Program received signal SIGSEGV, Segmentation fault.
0x00000000008046dc in fold_binary_loc ()
(gdb) bt
#0  0x00000000008046dc in fold_binary_loc ()
#1  0x00000000008905e2 in gimplify_expr ()
#2  0x0000000000895269 in ?? ()
#3  0x000000000089067e in gimplify_expr ()
#4  0x000000000089f7a2 in ?? ()
#5  0x0000000000891188 in gimplify_expr ()
#6  0x00000000008a22f9 in ?? ()
#7  0x000000000088fd3e in gimplify_expr ()
#8  0x0000000000898367 in gimplify_stmt ()
#9  0x000000000089f41d in ?? ()
#10 0x00000000008916f0 in gimplify_expr ()
#11 0x00000000008961b3 in ?? ()
#12 0x000000000088fcd5 in gimplify_expr ()
#13 0x0000000000898367 in gimplify_stmt ()
#14 0x0000000000890b9e in gimplify_expr ()
#15 0x0000000000898367 in gimplify_stmt ()
#16 0x0000000000898d5c in ?? ()
#17 0x0000000000891414 in gimplify_expr ()
#18 0x0000000000898367 in gimplify_stmt ()
#19 0x00000000008908a9 in gimplify_expr ()
#20 0x0000000000898367 in gimplify_stmt ()
#21 0x0000000000898d5c in ?? ()
#22 0x0000000000891414 in gimplify_expr ()
#23 0x0000000000898367 in gimplify_stmt ()
#24 0x00000000008908a9 in gimplify_expr ()
#25 0x0000000000898367 in gimplify_stmt ()
[...]

bug submitter writes:

- if you comment out the ~Base destructor, the ICE goes away.

- The ICE also goes away if you significantly reduce the number of Child
members in the Container class.

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

[rguenth at gcc dot gnu.org]

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?

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

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jason at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> 2011-07-18 14:17:34 UTC ---
(In reply to comment #1)
> 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:

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

The nesting is inherent in the language; after the initialization of an object
which needs a cleanup, anything that throws needs to destroy that object.  So
each variable implies a TRY_FINALLY_EXPR to follow it.

For walk_tree we could probably do tail recursion into the try operand, but
that won't work for gimplification since we need to process the try before the
finally.

I think cc1plus should use setrlimit to raise the stack size limit.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-18 14:24:56 UTC ---
More probably the gcc/g++ driver already, because inside of tbe main of a
program it might be too late to increase the stack limits - if something is
already mmapped right below the old smaller stack the increase won't be
effective.
I guess increasing the RLIMIT_STACK in the driver to MIN (hard_limit, MAX
(soft_limit, 30MB)) wouldn't be a bad idea.

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

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> 2011-07-18 15:22:11 UTC ---
For this testcase, even 30MB isn't enough, but 40MiB is, so I think I'll round
up to 64MB.

I think it's probably best to raise the limit in both places to avoid confusion
when invoking cc1plus directly.

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-18 19:30:03 UTC ---
Created attachment 24788
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24788
gcc47-pr49756.patch

Untested patch.  Clueless people will be still able to construct twice or 4
times as large testcases of similar quality when they really should be using an
array, but I guess this can help even with reasonable testcases.
The drawback is I think that endless recursion bugs might take much more
compile time before they fail.

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

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> 2011-07-18 19:34:08 UTC ---
Created attachment 24789
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24789
my patch

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

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-22 08:33:42 UTC ---
Author: jakub
Date: Fri Jul 22 08:33:37 2011
New Revision: 176617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176617
Log:
    PR c++/49756
    * libiberty.h (stack_limit_increase): New prototype.

    * stack-limit.c: New file.
    * Makefile.in: Regenerate deps.
    (CFILES): Add stack-limit.c.
    (REQUIRED_OFILES): Add ./stack-limit.$(objext).
    * configure.ac (checkfuncs): Add getrlimit and setrlimit.
    (AC_CHECK_FUNCS): Likewise.
    * configure: Regenerated.
    * config.in: Regenerated.

    * gcc.c (main): Call stack_limit_increase (64MB).
    * toplev.c (toplev_main): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gcc.c
    trunk/gcc/toplev.c
    trunk/include/ChangeLog
    trunk/include/libiberty.h
    trunk/libiberty/ChangeLog
    trunk/libiberty/Makefile.in
    trunk/libiberty/config.in
    trunk/libiberty/configure
    trunk/libiberty/configure.ac

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

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-22 09:21:52 UTC ---
Author: jakub
Date: Fri Jul 22 09:21:49 2011
New Revision: 176622

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176622
Log:
    PR c++/49756
    * libiberty.h (stack_limit_increase): New prototype.

    * stack-limit.c: New file.
    * Makefile.in: Regenerate deps.
    (CFILES): Add stack-limit.c.
    (REQUIRED_OFILES): Add ./stack-limit.$(objext).
    * configure.ac (checkfuncs): Add getrlimit and setrlimit.
    (AC_CHECK_FUNCS): Likewise.
    * configure: Regenerated.
    * config.in: Regenerated.

    * gcc.c (main): Call stack_limit_increase (64MB).
    * toplev.c (toplev_main): Likewise.

Added:
    trunk/libiberty/stack-limit.c

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

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|jason at gcc dot gnu.org    |unassigned at gcc dot
                   |                            |gnu.org

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> 2011-08-01 20:42:50 UTC ---
Fixed by Jakub's patch.