current CVS crashes in find_basic_blocks during bootstrap
Zack Weinberg
zack@wolery.cumb.org
Thu May 4 11:10:00 GMT 2000
This was with --enable-checking, but I doubt it's relevant.
$ gdb stage1/cc1
(gdb) r function.i -dumpbase function.c -g -O2 -O2 -W -Wall \
-Wtraditional -Wno-long-long -Wwrite-strings -pedantic -version -o \
function.s
GNU C version 2.96 20000504 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 2.95.2 20000313 (Debian GNU/Linux).
options passed: -g -O2 -O2 -W -Wall -Wtraditional -Wno-long-long
-Wwrite-strings -pedantic
...
fixup_var_refs_insns fixup_var_refs_1 {GC 5608k -> 2274k}
Program received signal SIGSEGV, Segmentation fault.
0x82c619c in make_edge (edge_cache=0x0, src=0x88c65a0, dst=0x0, flags=0)
at /work/src/on-ice.gcc/gcc/flow.c:1121
1121 e->pred_next = dst->pred;
(gdb) bt
#0 0x82c619c in make_edge (edge_cache=0x0, src=0x88c65a0, dst=0x0, flags=0)
at /work/src/on-ice.gcc/gcc/flow.c:1121
#1 0x82c64a4 in make_label_edge (edge_cache=0x0, src=0x88c65a0,
label=0x406828c0, flags=0) at /work/src/on-ice.gcc/gcc/flow.c:1153
#2 0x82c58ec in make_edges (label_value_list=0x0)
at /work/src/on-ice.gcc/gcc/flow.c:998
#3 0x82c2c61 in find_basic_blocks (f=0x40244440, nregs=1753, file=0x0)
at /work/src/on-ice.gcc/gcc/flow.c:458
#4 0x804e625 in rest_of_compilation (decl=0x4059ab00)
at /work/src/on-ice.gcc/gcc/toplev.c:2830
#5 0x871db37 in finish_function (nested=0)
at /work/src/on-ice.gcc/gcc/c-decl.c:6499
#6 0x86fc60a in yyparse () at c-parse.y:313
#7 0x804d033 in compile_file (name=0x40104230 "7")
at /work/src/on-ice.gcc/gcc/toplev.c:2262
#8 0x8051731 in main (argc=16, argv=0xbffffaa4)
at /work/src/on-ice.gcc/gcc/toplev.c:4637
# make_edge certainly shouldn't be called with dst 0.
# note: we're in jump1 here.
(gdb) up
#1 0x82c64a4 in make_label_edge (edge_cache=0x0, src=0x88c65a0,
label=0x406828c0, flags=0) at /work/src/on-ice.gcc/gcc/flow.c:1153
1153 make_edge (edge_cache, src, BLOCK_FOR_INSN (label), flags);
(gdb) p label
$1 = 0x406828c0
(gdb) pr
(code_label 3751 0 0 1155 "" "" [5 uses])
# that label isn't attached to the chain!
(gdb) p *basic_block_for_insn
$2 = {num_elements = 13960, elements_used = 0, element_size = 4,
name = 0x8763b7f "basic_block_for_insn", data = {c = "", uc = "", s = {0},
us = {0}, i = {0}, u = {0}, l = {0}, ul = {0}, hint = {0}, uhint = {0},
generic = {0x0}, cptr = {0x0}, rtx = {0x0}, rtvec = {0x0}, tree = {0x0},
bitmap = {0x0}, sched = {0x0}, reg = {0x0}, const_equiv = {{rtx = 0x0,
age = 0}}, bb = {0x0}, te = {0x0}}}
# we're not examining garbage memory (num_elements > INSN_UID (label)).
# speculation: the label was deleted, but the jumps referencing it
# were not.
(gdb) up
#2 0x82c58ec in make_edges (label_value_list=0x0)
at /work/src/on-ice.gcc/gcc/flow.c:998
998 make_label_edge (edge_cache, bb, JUMP_LABEL (insn), 0);
(gdb) l
994 else
995 {
996 if (! JUMP_LABEL (insn))
997 abort ();
998 make_label_edge (edge_cache, bb, JUMP_LABEL (insn), 0);
999 }
1000 }
(gdb) call debug_bb (bb)
;; Basic block 170, loop depth 0
;; Predecessors: 169 (fallthru)
;; Registers live at start: (nil)
(note 13238 3734 3738 [bb 170] NOTE_INSN_BASIC_BLOCK)
(insn 3738 13238 3739 (set (mem:SI (reg/v:SI 28) 6)
(reg/v:SI 26)) -1 (nil)
(nil))
(note 3739 3738 3740 ("/work/src/on-ice.gcc/gcc/function.c") 2086)
(insn 3740 3739 3742 (parallel[
(set (reg:SI 543)
(zero_extend:SI (mem/s:QI (plus:SI (reg/v:SI 26)
(const_int 2 [0x2])) 0)))
(clobber (reg:CC 17 flags))
] ) -1 (nil)
(nil))
(insn 3742 3740 3744 (set (reg/v:SI 26)
(reg/v:SI 26)) -1 (nil)
(nil))
(insn 3744 3742 3746 (set (reg/v:SI 27)
(reg:SI 543)) -1 (nil)
(nil))
(insn 3746 3744 3748 (set (reg/v:SI 28)
(reg/v:SI 28)) -1 (nil)
(nil))
(insn 3748 3746 3750 (set (reg/v:SI 29)
(reg/v:SI 29)) -1 (nil)
(nil))
(insn 3750 3748 3752 (set (reg/v:SI 30)
(reg/v:SI 30)) -1 (nil)
(nil))
(jump_insn 3752 3750 3753 (set (pc)
(label_ref 3751)) -1 (nil)
(nil))
;; Registers live at end: (nil)
;; Successors:
# most of those insns should've been zapped by jump_optimize... oh, we
# don't delete noop moves at this point. seems odd.
# i run out of ideas at this point. does anyone have a clue?
zw
More information about the Gcc-bugs
mailing list