http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957
--- Comment #4 from Andrey Belevantsev <abel at gcc dot gnu.org> 2013-04-17
05:14:44 UTC ---
(In reply to comment #2)
> Breakpoint 5, sel_remove_insn (insn=0x3fffb5da4e78, only_disconnect=false,
> full_tidying=false) at ../../trunk/gcc/sel-sched-ir.c:3938
> 3938 delete_insn (insn);
> 1: debug_rtx(insn) = (insn 303 190 191 10 (set (reg:DF 165 f37 [421])
> (unspec:DF [
> (mem:DF (reg/f:DI 18 r18 [420]) [2 *a_7(D) S8 A64])
> ] UNSPEC_LDA)) 13 {movdf_advanced}
> (nil))
You are right, this is not supposed to happen. The only_disconnect business is
for the unification and transformation support, when you have possibly several
insns as sources of the one chosen for scheduling. Thus, you need to delete
all sources but the one you're going to move upwards, and even this chosen one
should be deleted if it was changed while moving.
The insn in question is a speculative insn possibly generated earlier, so ...
> (gdb) p EXPR_WAS_CHANGED(expr)
> $22 = true
... if this is true, we are supposed to emit the new insn obviously with the
new id. The issue is that we then decide to emit the very same insn. I will
take a look.
