https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69102
--- Comment #4 from Andrey Belevantsev <abel at gcc dot gnu.org> --- Created attachment 37550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37550&action=edit proposed patch The problem here is readonly dependence contexts in selective scheduler. We're trying to cache the effect of initializing a dependence context with remembering that context and setting a readonly bit on it. When first moving the insn 43 with REG_ARGS_SIZE note through the insn 3 (a simple eax set) we also set the last_args_size field of the context. Later, when we make a copy of insn 43 and try to move it again through insn 3, we take the cached dependency context and notice the (fake) dep with last_args_size insn, which is the old insn 43. Then the assert saying that we should be able to lift the bookkeeping copy up the same way as we did with the original insn breaks. Fixed by the attached patch that makes us notice only deps with the current producer insn. I'd need to test it more thoroughly on several arches though. Richard, is it safe to make copies of REG_ARGS_SIZE insns? I've read the original ML thread of the sched-deps REG_ARGS_SIZE patch and couldn't quite figure it out -- with the current deps setting nothing prevents us from moving the first REG_ARGS_SIZE insn up and creating bookkeeping copies on the paths where it is inaccessible.
