[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

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

--- Comment #11 from Andrey Belevantsev <abel at gcc dot gnu.org> 2013-01-21 10:15:31 UTC ---
(In reply to comment #10)
> Neither insn 24/145 nor insn 28 move through insn 17. The two UNSPEC 44 insn
> (LC..2,, LCM..2) are inputs to insn 17. The pseudos are moved into r3 and r4,
> which are the inputs to insn 17.

You mean insn 23, not insn 28, right?  I'm not sure how insns 23/24 could be
inputs to insn 17, as they move up through insn 17.  I don't see full RTL so
I'm guessing here.

Unfortunately, libbacktrace didn't work for the dump you provided, so I only
see that for insn 23 we generate a "general dependency" meaning that it is not
connected to lhs or rhs of the insn, but I don't know where exactly it comes
from.  We do not generate such dependency for insn 24, while they differ only
in lhs -- the former having a pseudo, the latter a hard register r3.  I think
this could be fixed by making the same kind of dependency for insn 24, but I'm
unable to make the compiler generate it, as to get insn 17 I need TLS support
not available in the cross compiler.  

In general, would you allow insn 24 to move past insn 17 with the new register
or does it have to be r3 in insn 24?