https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #1) > Would be possible to analyze this a bit? I would leave it to you. Note that the same happens for SPEC2006 403.gcc benchmark: $ gdb --args /home/marxin/Programming/cpu2006/benchspec/CPU2006/403.gcc/run/run_peak_ref_amd64-m64-mine.0001/gcc_peak.amd64-m64-mine /home/marxin/Programming/cpu2006/benchspec/CPU2006/403.gcc/data/ref/input/scilab.in $ Breakpoint 1, remove_useless_values () at cselib.c:394 394 abort (); (gdb) bt #0 remove_useless_values () at cselib.c:394 #1 cselib_process_insn (insn=0x1200a40) at cselib.c:1377 #2 0x000000000046fd48 in reload_cse_regs_1 (first=<optimized out>) at reload1.c:8172 #3 0x00000000004700db in reload_cse_regs (first=0xd928c0) at reload1.c:8186 #4 0x000000000044a3ec in rest_of_compilation (decl=0x954000) at toplev.c:3254 #5 0x00000000005edd56 in c_expand_body.part.1.lto_priv.1473 (fndecl=fndecl@entry=0x954000, nested_p=nested_p@entry=0, can_defer_p=can_defer_p@entry=1) at c-decl.c:7119 #6 0x00000000005ee710 in c_expand_body (can_defer_p=1, nested_p=0, fndecl=0x954000) at c-decl.c:7024 #7 finish_function (nested=0, can_defer_p=1) at c-decl.c:6986 #8 0x00000000006072c0 in yyparse_1 () at c-parse.c:2186 #9 0x0000000000402fec in yyparse () at c-lex.c:164 #10 compile_file () at toplev.c:2126 #11 do_compile () at toplev.c:5221 #12 toplev_main (argv=<optimized out>, argc=<optimized out>) at toplev.c:5255 #13 main (argc=<optimized out>, argv=<optimized out>) at main.c:35 The patch does have effect on > optimizers because we produce a lot fewer MEM_REFs on type mismatches. Of > course this should not trigger wrong code but it also may be some bug in > benchmark or so. I doubt that.
