segfault in init_elem_table in reload1.c

[Nathan Sidwell]

Hi,
I've come across a problem with eliminate_regs, when called dbxout_symbol. It seems
that Jeff Law's patch
Sat Nov 21 22:12:09 1998  Jeffrey A Law  (law@cygnus.com)

        * reload1.c (eliminate_regs): Do not lose if eliminate_regs is called
        without reload having been called earlier.

doesn't quite do the right thing. (Though I'm not sure what the right thing is,
otherwise I'd do it myself.) init_elim_table seems to be doing something context
specific about initing the elimination table.

Example program and compiler output attached.

init_elim_table contains a call to FRAME_POINTER_REQUIRED, which on this sparc box
ends up calling leaf_function_p (final.c). That uses get_insns (emit_rtl.c). However,
the static variables that get_insns uses are not valid at this point (they point
to outdated rtl). So we soon get a seg fault.

Here's the compile line for the 19981122 snapshot,
nathan@laie:39>uname -a
SunOS laie 5.5.1 Generic sun4u sparc SUNW,Ultra-1
nathan@laie:40>./cc1plus -g -O2 ../../bugs/segfault.ii

I've attached the output of this. The bug is only tickled when both 
O2 and -g are given. I'm sorry I can't produce a smaller test case. I tried
reducing it, but the bug envelope seems so fragile that it kept disappearing.
Here's the stack traceback of cc1plus at the point of the segfault.

Program received signal SIGBUS, Bus error.
0x14239c in leaf_function_p () at final.c:3983
3983      for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
(gdb) back
#0  0x14239c in leaf_function_p () at final.c:3983
#1  0x111f28 in init_elim_table () at reload1.c:3665
#2  0x110534 in eliminate_regs (x=0x8626f8, mem_mode=VOIDmode, insn=0x0) at reload1.c:2653
#3  0x86e20 in dbxout_symbol (decl=0x862620, local=0) at dbxout.c:1936
#4  0x6cfdc in assemble_variable (decl=0x862620, top_level=1, at_end=8791816, dont_output_data=0) at varasm.c:1474
#5  0x13930 in rest_of_decl_compilation (decl=0x862620, asmspec=0x0, top_level=1, at_end=0) at toplev.c:3200
#6  0x196f18 in cp_finish_decl (decl=0x862620, init=0x0, asmspec_tree=0x0, need_pop=1, flags=128) at decl.c:7602
#7  0x1d6878 in yyparse () at parse.y:1910
#8  0x12e8c in compile_file (name=0xeffff71d "../../bugs/segfault.ii") at toplev.c:2822
#9  0x16a64 in main (argc=4, argv=0xeffff5c4) at toplev.c:4952

(gdb) print insn
$1 = 0xeffff71d

(gdb) print first_insn
$1 = 0x85fe00

(gdb) print *first_insn
$2 = {code = UNKNOWN, mode = VOIDmode, jump = 0, call = 0, unchanging = 0, volatil = 0, in_struct = 0, used = 0, integrated = 0, frame_related = 0, 
  fld = {{rtwint = 3195736, rtint = 3195736, rtstr = 0x30c358 "", rtx = 0x30c358, rtvec = 0x30c358, rttype = 3195736, rt_addr_diff_vec_flags = {
        min_align = 0, base_after_vec = 0, min_after_vec = 0, max_after_vec = 1, min_after_base = 1, max_after_base = 0, offset_unsigned = 0,  = 0, 
        scale = 195}, rtbit = 0x30c358, rttree = 0x30c358}}}

(gdb) print first_insn->fld[2].rtx
$3 = (struct rtx_def *) 0xeffff71d

that last address effff718 points to the source file name! And you'll notice
that first_insn (0x85fe00) is not the first instruction of the rtl passed to
eliminate_regs (0x8626f8).

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: segfault.ii.gz
Type: application/x-gzip
Size: 16800 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-bugs/attachments/19981203/38c50d85/attachment.bin>