Bootstrap failure on native Linux x86 - crashes in flow.c

[Greg McGary <gkm at eng dot ascend dot com>]

Richard,

The ChangeLog shows you checked stuff into flow.c yesterday, so I'll
badger you about it personally.  8^)

On a tree updated from CVS within the hour,
stage1/cc1 takes a SEGV compiling tree.c and emit-rtl.c

The tree.c crash happens here:

static void
mark_set_1 (needed, dead, x, insn, significant, flags)
     ...
{
     ...
      if (flags & (PROP_LOG_LINKS | PROP_REG_INFO
		   | PROP_DEATH_NOTES | PROP_AUTOINC))
	{
	  register rtx y;
=>	  register int blocknum = BLOCK_NUM (insn);

because (basic_block_for_insn == NULL).

Here's a backtrace:

#1  0x8144120 in mark_set_regs (needed=0xbfffd9f0, dead=0xbfffd960, x=0x403a5300, insn=0x403a6a00, significant=0x0, flags=1) at ../../src/gcc/flow.c:3769
(gdb) fr 0
#0  0x81444f9 in mark_set_1 (needed=0xbfffd9f0, dead=0xbfffd960, x=0x403a5300, insn=0x403a6a00, significant=0x0, flags=1) at ../../src/gcc/flow.c:3931
(gdb) bt
#0  0x81444f9 in mark_set_1 (needed=0xbfffd9f0, dead=0xbfffd960, x=0x403a5300, insn=0x403a6a00, significant=0x0, flags=1) at ../../src/gcc/flow.c:3931
#1  0x8144120 in mark_set_regs (needed=0xbfffd9f0, dead=0xbfffd960, x=0x403a5300, insn=0x403a6a00, significant=0x0, flags=1) at ../../src/gcc/flow.c:3769
#2  0x81437f1 in propagate_block (old=0xbfffd9f0, first=0x403a4e20, last=0x403a7000, significant=0x0, bnum=8, flags=1) at ../../src/gcc/flow.c:3391
#3  0x8141a38 in update_life_info (blocks=0x83476a8, extent=UPDATE_LIFE_GLOBAL_RM_NOTES) at ../../src/gcc/flow.c:2578
#4  0x814ac50 in combine_instructions (f=0x4039e620, nregs=87) at ../../src/gcc/combine.c:699
#5  0x804d1cc in rest_of_compilation (decl=0x40297c00) at ../../src/gcc/toplev.c:4037
#6  0x828e4c6 in finish_function (nested=0) at ../../src/gcc/c-decl.c:6715
#7  0x827b1da in yyparse () at c-parse.y:314
#8  0x804b844 in compile_file (name=0x400c02d0 "tree.i") at ../../src/gcc/toplev.c:3200
#9  0x804f95e in main (argc=14, argv=0xbffff314) at ../../src/gcc/toplev.c:5552

Does this look familiar?

I also noticed a stylistic nit: find_basic_blocks is called outside of
life_analysis, and with exactly the same args as are passed to
life_analysis.  free_basic_block_vars is called inside life_analysis.
It seems to me that find_basic_blocks should be called inside
life_analysis at the top of the function.

Greg