http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
--- Comment #8 from Andrey Belevantsev <abel at gcc dot gnu.org> 2013-01-18 11:09:13 UTC --- Created attachment 29202 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29202 more debug printing patch >From the log, the problem looks as follows. There is insn 24, %3=[unspec[`*LCM..2',%2], which is allowed to move past insn 17, {%3=unspec[%3,%4] 25;clobber %0;clobber %4;clobber %5;clobber %11;clobber %0;clobber lr;}, given that its target register will be renamed. After renaming, it shows as insn 145, r192=[unspec[`*LCM..2',%2] 44] but this insn is suddenly can not be moved through insn 17, thus the scheduler aborts. The question is why insn 145 or insn 23, which looks like r148=[unspec[`*LC..2',%2] 44] (same unspec code, etc), cannot be moved through insn 17 while insn 24 can. Attached is the patch that produces lots of debug output from the dependency analysis. David, could you apply it on top of the previous one and run the test case with -fsched-verbose=9 this time? (It uses libbacktrace, I'm not sure whether AIX is fine with that, but even without this there will be a lot more information.) Also, if you can clarify the above question on what is different between insns 23/145 and 24 from the target point of view, it would help a lot.
