> > Perhaps it would be safer simply to revert that hunk of the original patch > > unless/until (1) and (2) above are addressed? > > Given that the original patch addresses 'only' a missed-optimization > (and causes ice-on-valid), it makes sense to me.
(1) Iain already asked the questions more than two months ago at https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00374.html without answer AFAICT. (2) I think it is enough to revert the commit of gcc/config/i386/i386.c as --- ../_clean/gcc/config/i386/i386.c 2014-09-12 23:04:53.000000000 +0200 +++ gcc/config/i386/i386.c 2014-09-12 15:55:34.000000000 +0200 @@ -38965,16 +38965,7 @@ x86_output_mi_thunk (FILE *file, tree, H For our purposes here, we can get away with (ab)using a jump pattern, because we're going to do no optimization. */ if (MEM_P (fnaddr)) - { - if (sibcall_insn_operand (fnaddr, word_mode)) - { - tmp = gen_rtx_CALL (VOIDmode, fnaddr, const0_rtx); - tmp = emit_call_insn (tmp); - SIBLING_CALL_P (tmp) = 1; - } - else - emit_jump_insn (gen_indirect_jump (fnaddr)); - } + emit_jump_insn (gen_indirect_jump (fnaddr)); else { if (ix86_cmodel == CM_LARGE_PIC && SYMBOLIC_CONST (fnaddr)) see https://gcc.gnu.org/ml/gcc-testresults/2014-09/msg01414.html Dominique
