Re: Virtual memory exhausted

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello.

> > Compiling stage1/objc-act.c with CVS as of 30 mins ago.
> > 
> > It had consumed well over 600MB when it died.
> 
> A backtrace at 200MB gives:
> 
> #0  0x083501d5 in bitmap_element_zerop (element=0x88d699c)
>     at ../../gcc/bitmap.c:155
> #1  0x0834faa4 in bitmap_operation (to=0xbfffe980, from1=0xbfffe980, 
>     from2=0x88d128c, operation=BITMAP_IOR) at ../../gcc/bitmap.c:633
> #2  0x08160109 in calculate_global_regs_live (blocks_in=0x88b4010, 
>     blocks_out=0x88b4010, flags=16) at ../../gcc/flow.c:1192
> #3  0x0815ef3b in update_life_info (blocks=0x88b4010, 
>     extent=UPDATE_LIFE_GLOBAL_RM_NOTES, prop_flags=27) at
> ../../gcc/flow.c:661
> #4  0x0815f631 in update_life_info_in_dirty_blocks (
>     extent=UPDATE_LIFE_GLOBAL_RM_NOTES, prop_flags=27) at
> ../../gcc/flow.c:792
> #5  0x083595dc in cleanup_cfg (mode=35) at ../../gcc/cfgcleanup.c:1802
> #6  0x082fdd8f in rest_of_compilation (decl=0x406cc700)
>     at ../../gcc/toplev.c:3242
> #7  0x0807315d in c_expand_body (fndecl=0x406cc700, nested_p=0,
> can_defer_p=1)
>     at ../../gcc/c-decl.c:6840
> #8  0x08072c92 in finish_function (nested=0, can_defer_p=1)
>     at ../../gcc/c-decl.c:6707
> #9  0x0804a758 in yyparse () at c-parse.y:400
> #10 0x08056604 in c_common_parse_file (set_yydebug=0) at
> ../../gcc/c-lex.c:161
> #11 0x082fb495 in compile_file () at ../../gcc/toplev.c:2063
> #12 0x08301281 in do_compile () at ../../gcc/toplev.c:5151
> #13 0x083012da in toplev_main (argc=58, argv=0xbffff764)
>     at ../../gcc/toplev.c:5183
> #14 0x080c13ca in main (argc=58, argv=0xbffff764) at ../../gcc/main.c:35
> #15 0x400376cf in __libc_start_main () from /lib/libc.so.6
> 
> so I suspect this patch:
> 
> 2002-05-16  Zdenek Dvorak
> 
> 	Basic block renumbering removal:
> 	* basic_block.h (struct basic_block_def): Renamed index to
> 	* sindex,
> 	added prev_bb and next_bb fields.
> 	(n_basic_blocks): Renamed to num_basic_blocks.
> 	(last_basic_block): New, index of last basic block.
> 	(FOR_BB_BETWEEN, FOR_ALL_BB, FOR_ALL_BB_REVERSE): New macros for
> 	traversing basic block chain.
> 	(BLOCK_NUM): index -> sindex.
> 	(create_basic_block_structure, create_basic_block): Declaration
> changed.
> 	(debug_num2bb): Declare.
> 	(expunge_block_nocompact): Declaration removed.
> 	(link_block, unlink_block, compact_blocks): Declare.
> 	* bb-reorder.c (make_reorder_chain, make_reorder_chain_1):
> [SNIP]

This patch fixes it. Note that it seems that real problem is not in my patch,
but in fact that iterative dataflow does not have to terminate if initial
solution is not empty. I suppose that the fact that ordering of basic blocks
respects loop structure of program most of the time probably causes this not to
manifest (unless something like my patch changes the order).

Zdenek Dvorak

Index: flow.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/flow.c,v
retrieving revision 1.517
diff -c -3 -p -r1.517 flow.c
*** flow.c	16 May 2002 17:34:35 -0000	1.517
--- flow.c	16 May 2002 22:24:40 -0000
*************** calculate_global_regs_live (blocks_in, b
*** 1115,1128 ****
      {
        /* Clear out the garbage that might be hanging out in bb->aux.  */
        FOR_ALL_BB (bb)
- 	bb->aux = NULL;
- 
-       EXECUTE_IF_SET_IN_SBITMAP (blocks_in, 0, i,
  	{
! 	  bb = BASIC_BLOCK (i);
  	  *--qhead = bb;
  	  bb->aux = bb;
! 	});
      }
    else
      {
--- 1115,1129 ----
      {
        /* Clear out the garbage that might be hanging out in bb->aux.  */
        FOR_ALL_BB (bb)
  	{
! 	  bb->aux = NULL;
! 
! 	  if (!TEST_BIT (blocks_in, bb->sindex))
! 	    continue;
! 
  	  *--qhead = bb;
  	  bb->aux = bb;
! 	}
      }
    else
      {