[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #17 from jsm28 at gcc dot gnu dot org 2008-08-27 22:04 --- 4.3.2 is released, changing milestones to 4.3.3. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.2 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #16 from aaronavay62 at aaronwl dot com 2008-08-23 18:06 --- (In reply to comment #15) This should be fixed on the trunk by 2008-08-20 Richard Guenther [EMAIL PROTECTED] 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=0x11) at ../../svn/gcc/passes.c:943 #10857 0x005265a0 in do_per_function ( callback=0x52629c execute_function_todo, data=0x11) 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. -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Last reconfirmed|2008-07-14 08:03:23 |2008-08-23 18:06:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-08-22 19:28 --- This should be fixed on the trunk by 2008-08-20 Richard Guenther [EMAIL PROTECTED] * 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. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #14 from aph at gcc dot gnu dot org 2008-07-30 09:23 ---
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;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #13 from aaronavay62 at aaronwl dot com 2008-07-14 08:03 --- 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 -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Last reconfirmed|2008-06-11 10:50:09 |2008-07-14 08:03:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #9 from ian at airs dot com 2008-06-14 05:59 --- 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. -- ian at airs dot com changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #10 from aph at gcc dot gnu dot org 2008-06-14 06:27 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #11 from dannysmith at users dot sourceforge dot net 2008-06-14 10:01 --- (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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #12 from aaronavay62 at aaronwl dot com 2008-06-14 15:43 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #8 from mmitchel at gcc dot gnu dot org 2008-06-13 21:41 --- Ian -- Do you have any thoughts about this issue? -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||ian at airs dot com Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #7 from aph at gcc dot gnu dot org 2008-06-11 10:49 --- 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. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-11 10:49:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-06-08 16:15 ---
Subject: Bug 36218
Author: jsm28
Date: Sun Jun 8 16:14:33 2008
New Revision: 136563
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=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 @[EMAIL PROTECTED]
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-06-08 16:37 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-22 20:10 --- VRP did not exist in 4.0.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to work||4.0.0 Summary|[4.4 regression] VRP causes |[4.2/4.3/4.4 regression] VRP |stack overflow while|causes stack overflow while |building libgcj |building libgcj Target Milestone|4.4.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
