[Bug target/15491] ICE (Internal compiler error) while compiling glibc to vax-linux target

["jbglaw at lug-owl dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jbglaw at lug-owl dot de  2004-05-27 13:17 -------
(From update of attachment 6399)
>Program received signal SIGSEGV, Segmentation fault.
>vax_rtx_costs_1 (x=0x40273ea0, code=SYMBOL_REF, outer_code=INSN_LIST)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/config/vax/vax.c:709
>709           code = GET_CODE (op);
>(gdb) bt
>#0  vax_rtx_costs_1 (x=0x40273ea0, code=SYMBOL_REF, outer_code=INSN_LIST)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/config/vax/vax.c:709
>#1  0x082ee7cf in vax_rtx_costs (x=0x2, code=2, outer_code=2, total=0x4f)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/config/vax/vax.c:764
>#2  0x082a0998 in rtx_cost (x=0x40273ea0, outer_code=INCLUDE)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/rtlanal.c:3815
>#3  0x08160241 in notreg_cost (x=0x40273ea0, outer=INCLUDE)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/cse.c:809
>#4  0x0816841b in cse_insn (insn=0x402adb84, libcall_insn=0x0)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/cse.c:5246
>#5  0x0816a5c6 in cse_basic_block (from=0x40270e34, to=0x402add68, next_branch=0x84304b0, around_loop=1)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/cse.c:7124
>#6  0x0816a240 in cse_main (f=0x0, nregs=-1073749120, after_loop=0, file=0x0)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/cse.c:6985
>#7  0x082eb0d2 in rest_of_handle_cse (decl=0x2, insns=0x40270e34)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/passes.c:1121
>#8  0x082ebc2e in rest_of_compilation (decl=0x4029d414)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/passes.c:1562
>#9  0x080c60b2 in tree_rest_of_compilation (fndecl=0x4029d414, nested_p=false)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/tree-optimize.c:590
>#10 0x08063a68 in c_expand_body_1 (fndecl=0x4029d414, nested_p=0)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/c-decl.c:6380
>#11 0x08063c03 in c_expand_body (fndecl=0x4f) at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/c-decl.c:6403
>#12 0x082f7242 in cgraph_expand_function (node=0x402a5e80)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/cgraphunit.c:794
>#13 0x082f629a in cgraph_assemble_pending_functions ()
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/cgraphunit.c:295
>#14 0x082f63d6 in cgraph_finalize_function (decl=0x4029d414, nested=false)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/cgraphunit.c:376
>#15 0x080633ef in c_finalize (fndecl=0x4029d414)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/c-decl.c:6222
>#16 0x08063638 in finish_function () at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/c-decl.c:6345
>#17 0x0804a3c7 in yyparse () at c-parse.y:372
>#18 0x0805191b in c_parse_file () at c-parse.y:3015
>#19 0x0809765b in c_common_parse_file (set_yydebug=2)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/c-opts.c:1239
>#20 0x082bcf7a in compile_file () at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/toplev.c:1653
>#21 0x082be485 in do_compile () at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/toplev.c:2699
>#22 0x082be4f5 in toplev_main (argc=2, argv=0xbfffeef4)
>    at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/toplev.c:2731
>#23 0x080add1b in main (argc=2, argv=0x2) at /home/jbglaw/vax-linux/toolchain/__temp/source/gcc-HEAD/gcc/main.c:35
>(gdb) print op
>$1 = 0x0

So this segv happens in cost estimation. Could someone please review the code a
bit? In pristine sources, this is
right after while (*fmt++ == 'e') (in vax_rtx_costs_1()): register rtx op =
XEXP (x, i++); results in a NULL ptr,
which the next statement (code = GET_CODE (op);;) then tries to dereference ...

I think the NetBSD guys could be interested in this, too...

MfG, JBG


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15491