Bug 36218 - [4.3 Regression] VRP causes stack overflow while building libgcj
Summary: [4.3 Regression] VRP causes stack overflow while building libgcj
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.4.0
: P2 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: build
Depends on:
Blocks: 36216
  Show dependency treegraph
 
Reported: 2008-05-12 11:01 UTC by Aaron W. LaFramboise
Modified: 2011-06-27 11:24 UTC (History)
6 users (show)

See Also:
Host: i386-pc-mingw32
Target:
Build:
Known to work: 4.0.0, 4.4.0
Known to fail: 4.2.0, 4.3.0, 4.4.0
Last reconfirmed: 2008-09-20 15:09:14


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron W. LaFramboise 2008-05-12 11:01:45 UTC
Several files in libgcj will cause jc1.exe to exhaust its stack space allocation.

This can be worked around by compiling jc1.exe with -Wl,--stack,0x2000000, which can be accomplished by including it in LDFLAGS when compiling.  (This exact size is arbitrary; it's big enough to work, but perhaps much too big.)

The cause seems to be massive recursion between find_assert_locations() and find_conditional_asserts().  I'm not sure if this is intended behavior.

If this is intended behavior, it's not clear to me what the right thing to do to fix this is.  What negative consequences does increasing the default allocation have?  Is it possible to adjust this limit at runtime, perhaps as needed?
Comment 1 Aaron W. LaFramboise 2008-05-12 11:03:47 UTC
cipher.o at least fails for this reason.

I'm not sure when this last worked, but it at least worked sometime around 2004.
Comment 2 Danny Smith 2008-05-13 03:52:55 UTC
(In reply to comment #0)
>  What negative consequences does increasing the default [stack]
> allocation have?  
Minimal really, for a single threaded program like jc1.exe.  We are just reserving address space not actual memory.  In a multithreaded app, each thread reserves the same amount of address space as the primary thread (by default, but the default can be overiden), so too high a stack reserve for main thread can limit what is available for others.  



Is it possible to adjust this limit at runtime, perhaps as
> needed?
> 
No, not for main thread. It is built into the program header on MS windows.
GNAT also bumps stack reserve to 32 MB for "non-tasking" apps.  See system-mingw.ads.  

In old days, 32 MB was default for win32 in gnu ld.
Danny


Comment 3 Andrew Pinski 2008-05-22 20:10:30 UTC
VRP did not exist in 4.0.0.
Comment 4 Richard Biener 2008-06-06 14:59:24 UTC
4.3.1 is being released, adjusting target milestone.
Comment 5 Joseph S. Myers 2008-06-08 16:15:11 UTC
Subject: Bug 36218

Author: jsm28
Date: Sun Jun  8 16:14:33 2008
New Revision: 136563

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136563
Log:
	PR tree-optimization/36218
	* Makefile.def (flags_to_pass): Add LDFLAGS_FOR_BUILD.
	* Makefile.tpl (EXTRA_BUILD_FLAGS): Define.
	(all prefix="build-"): Pass them to build-system sub-makes.
	* Makefile.in: Regenerate.

config:
	* config/mh-mingw (LDFLAGS): Define.

gcc:
	* configure.ac: Use LDFLAGS="${LDFLAGS_FOR_BUILD}" when running
	configure for the build system.
	(BUILD_LDFLAGS): Define.
	* configure: Regenerate.
	* Makefile.in (BUILD_LDFLAGS): Define to @BUILD_LDFLAGS@.

Modified:
    trunk/ChangeLog
    trunk/Makefile.def
    trunk/Makefile.in
    trunk/Makefile.tpl
    trunk/config/ChangeLog
    trunk/config/mh-mingw
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/configure
    trunk/gcc/configure.ac

Comment 6 Joseph S. Myers 2008-06-08 16:37:27 UTC
Note that a native build should be done to verify that my patch increases the stack limit enough to fix this bug, before marking it fixed.
Comment 7 Andrew Haley 2008-06-11 10:49:26 UTC
This isn't just a mingw bug.  It is also manifested in GNU/Linux if gcc itself is built with -O0, as you need to do when debugging gcc.

There perhaps should be some limit to how far VRP goes before giving up.
Comment 8 Mark Mitchell 2008-06-13 21:41:25 UTC
Ian --

Do you have any thoughts about this issue?

-- Mark
Comment 9 Ian Lance Taylor 2008-06-14 05:59:26 UTC
There aren't any obvious instructions on how to reproduce this bug.  Andrew, which file(s) in libgcj do you see problems with?

Adding Diego to CC since VRP is his baby.
Comment 10 Andrew Haley 2008-06-14 06:27:46 UTC
The only way I can find out which file in libgcj causes the stack overflow is to try to build it again with an unoptimized gcc.  I can do so next week.
Comment 11 Danny Smith 2008-06-14 10:01:37 UTC
(In reply to comment #6)
> Note that a native build should be done to verify that my patch increases the
> stack limit enough to fix this bug, before marking it fixed.
> 

With this patch (8 mb stack reserve), native mingw32 jc1.exe (built with -O2)  is able to compile all libgcj objects on trunk and 4_3-branch. 

Danny
Comment 12 Aaron W. LaFramboise 2008-06-14 15:43:42 UTC
(In reply to comment #9)
> There aren't any obvious instructions on how to reproduce this bug.  Andrew,
> which file(s) in libgcj do you see problems with?

If you build libjava on a Win32 (mingw32 or Cygwin) target without altering ld's default stack reserve, cipher.o will fail to build with a stack overflow.
Comment 13 Aaron W. LaFramboise 2008-07-14 08:03:21 UTC
Joseph's patch doesn't work for me, because the --stack parameter never makes it to the link line for some reason, and I get the same crash building cipher.o.  This is the relevant output of bootstrap:

rm -f jc1.exe
/mingw/src/gccf/./prev-gcc/xgcc -B/mingw/src/gccf/./prev-gcc/ -B/mingw/i386-pc-mingw32/bin/  -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
                             -Wno-overlength-strings -Werror -fno-common  -DHAVE
_CONFIG_H  -o jc1.exe \
                java/class.o java/decl.o java/expr.o java/constants.o java/lang.o java/typeck.o java/except.o java/verify-glue.o java/verify-impl.o java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o java/mangle_name.o java/builtins.o java/resource.o java/jcf-depend.o java/jcf-path.o java/boehm.o java/java-gimplify.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L../zlib -lz  ../libcpp/libcpp.a ./../intl/libintl.a  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a attribs.o -L/mingw/src/gmp-mpfr/root/lib -L/mingw/src/gmp-mpfr/root/lib -lmpfr -lgmp

I don't know if there is something particular to the way I've configured that might be making this break for me.  As an additional data point, for some reason when I tried overriding LDFLAGS previously, the stack parameter also did not propagate properly to jc1.exe, although it propagated just fine to some of the other link lines outside of Java.

../svn/configure --enable-languages=c,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-concept-checks --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp-mpfr/root --with-mpfr=/mingw/src/gmp-mpfr/root --with-libiconv-prefix=/mingw/src/libiconv/root
make
Comment 14 Andrew Haley 2008-07-30 09:23:05 UTC
This patch limits recursion in tree-vrp.

Index: tree-vrp.c
===================================================================
--- tree-vrp.c	(revision 136670)
+++ tree-vrp.c	(working copy)
@@ -4049,6 +4049,8 @@
    the predicate operands, an assert location node is added to the
    list of assertions for the corresponding operands.  */
 
+static size_t depth;
+
 static bool
 find_conditional_asserts (basic_block bb, tree last)
 {
@@ -4062,6 +4064,10 @@
   need_assert = false;
   bsi = bsi_for_stmt (last);
 
+  depth++;
+  if (depth > 500)
+    goto ret;
+
   /* Look for uses of the operands in each of the sub-graphs
      rooted at BB.  We need to check each of the outgoing edges
      separately, so that we know what kind of ASSERT_EXPR to
@@ -4121,6 +4127,8 @@
   FOR_EACH_SSA_TREE_OPERAND (op, last, iter, SSA_OP_USE)
     SET_BIT (found_in_subgraph, SSA_NAME_VERSION (op));
 
+ ret:
+  depth--;
   return need_assert;
 }
 
Comment 15 Richard Biener 2008-08-22 19:28:02 UTC
This should be fixed on the trunk by

2008-08-20  Richard Guenther  <rguenther@suse.de>

        * tree-vrp.c (found_in_subgraph): Remove.
        (live): New global static.
        (live_on_edge): New function.
        (blocks_visited): Remove.
        (register_edge_assert_for_2): Use live_on_edge.
        (find_conditional_asserts): Remove code dealing with
        found_in_subgraph.  Do not walk the CFG.
        (find_switch_asserts): Likewise.
        (find_assert_locations_1): Renamed from find_assert_locations.
        Move finding assert locations for conditional and switch
        statements first.  Update live bitmap.  Do not walk the CFG.
        (find_assert_locations): New function.
        (insert_range_assertions): Remove entry of CFG walk.
        Adjust call to find_assert_locations.


can someone verify this?  Thanks.
Comment 16 Aaron W. LaFramboise 2008-08-23 18:06:02 UTC
(In reply to comment #15)
> This should be fixed on the trunk by
> 2008-08-20  Richard Guenther  <rguenther@suse.de>

> can someone verify this?  Thanks.

Yes and no.

On revision 139510 (2008-08-23), the compilation of cipher.lo is successful in a normal build, so I presume that the VRP problem has been fixed.  Yay!

However, there is a new (since April 2008) stack overflow now in HTML_401F.lo.  This one does not seem to be VRP-related, as -fno-tree-vrp does not seem to help.  It does, however, compile with -O0.  Here is the backtrace:

#0  0x00a61805 in htab_find_slot_with_hash (htab=0x5745038, element=0x83060,
    hash=13718576, insert=INSERT) at ../../svn/libiberty/hashtab.c:610
#1  0x00a61a82 in htab_find_slot (htab=0x5745038, element=0x83060,
    insert=INSERT) at ../../svn/libiberty/hashtab.c:678
#2  0x0076562a in set_livein_block (var=0x68aa180, bb=0x54c3dc0)
    at ../../svn/gcc/tree-into-ssa.c:503
#3  0x00766ae1 in prepare_block_for_update (bb=0x54c3dc0,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2364
#4  0x00766cf0 in prepare_block_for_update (bb=0x54c3d00,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
#5  0x00766cf0 in prepare_block_for_update (bb=0x54c3c00,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
...
#10851 0x00766cf0 in prepare_block_for_update (bb=0x4f63600,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
#10852 0x00766cf0 in prepare_block_for_update (bb=0x4f63580,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
#10853 0x00766cf0 in prepare_block_for_update (bb=0x4f63500,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
#10854 0x00769e62 in update_ssa (update_flags=2048)
    at ../../svn/gcc/tree-into-ssa.c:3230
#10855 0x00762164 in compute_may_aliases ()
    at ../../svn/gcc/tree-ssa-alias.c:1842
#10856 0x0052644d in execute_function_todo (data=0x100001)
    at ../../svn/gcc/passes.c:943
#10857 0x005265a0 in do_per_function (
    callback=0x52629c <execute_function_todo>, data=0x100001)
    at ../../svn/gcc/passes.c:837
#10858 0x00526670 in execute_todo (flags=1048577)
    at ../../svn/gcc/passes.c:1021
#10859 0x00526954 in execute_one_pass (pass=0xb05150)
    at ../../svn/gcc/passes.c:1297
#10860 0x00526b48 in execute_pass_list (pass=0xb05150)
    at ../../svn/gcc/passes.c:1323
#10861 0x00526b5b in execute_pass_list (pass=0xb04f10)
    at ../../svn/gcc/passes.c:1324
#10862 0x00759fb0 in tree_rest_of_compilation (fndecl=0x28c6c80)
    at ../../svn/gcc/tree-optimize.c:418
#10863 0x0058796f in cgraph_expand_function (node=0x47acc80)
    at ../../svn/gcc/cgraphunit.c:1039
#10864 0x0058968a in cgraph_optimize () at ../../svn/gcc/cgraphunit.c:1101
#10865 0x00443615 in java_parse_file (set_yydebug=0)
    at ../../svn/gcc/java/jcf-parse.c:1961
#10866 0x0047907d in toplev_main (argc=32, argv=0x31934e8)
    at ../../svn/gcc/toplev.c:959
#10867 0x0040124b in __mingw_CRTStartup ()
#10868 0x00401298 in mainCRTStartup ()

Should I open a new PR for this different stack overflow, and close this one?

I still have not had a chance to see why Joseph's change to LDFLAGS to make MinGW use the same stack allocation as Linux when building GCC does not propagate into libjava.  Once that is fixed, this entire catagory of MinGW-specific problems should go away.

So alternately we could close this one, and open a new one just for the LDFLAGS issue.
Comment 17 Joseph S. Myers 2008-08-27 22:04:00 UTC
4.3.2 is released, changing milestones to 4.3.3.
Comment 18 Richard Biener 2008-09-20 15:09:14 UTC
Please open a new report for the SSA update problem.  Back to NEW for this
PR, fixed on the trunk.  *-*-mingw* is not in the list of primary or secondary
platforms, so P4.
Comment 19 Brian Dessent 2008-09-20 17:32:08 UTC
Subject: Re:  [4.2/4.3 Regression] VRP causes stack 
 overflow while building libgcj

> PR, fixed on the trunk.  *-*-mingw* is not in the list of primary or secondary
> platforms, so P4.

As of 4.3 both MinGW and Cygwin are secondary targets:
<http://gcc.gnu.org/gcc-4.3/criteria.html>.
Comment 20 Richard Biener 2008-09-20 17:51:49 UTC
Oops.
Comment 21 Joseph S. Myers 2009-03-31 20:50:51 UTC
Closing 4.2 branch.
Comment 22 Richard Biener 2009-08-04 12:29:07 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 23 Richard Biener 2010-05-22 18:12:22 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 24 Richard Biener 2011-06-27 11:24:32 UTC
Fixed in 4.4.0.