[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj

["aaronavay62 at aaronwl dot com" <gcc-bugzilla@gcc.gnu.org>]

------- 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  <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.


-- 

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