https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-08-01
CC| |aoliva at gcc dot gnu.org,
| |bernds at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |vmakarov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Both the short #c0 and large #c3 testcases broke with r192203, the
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00752.html patch to remember DFA
state in between basic blocks.
In the short testcase I see that in bb3 with -g there is an extra tick at the
end of the bb added for the debug insn, which in itself is not a bug IMHO, it
is preceeded by asm which probably doesn't want to coexist in the same cycle
with anything else. Normally, if the debug insn was followed by any normal
insns, those would be scheduled in the same tick as the debug insn, but now
with this DFA state save/restore it apparently is an issue (I see the first
insn in the bb4 is scheduled in the first tick for that bb, but the second insn
differs between -g and -g0 - for -g it is scheduled in tick 1, for -g0 still in
tick 0, due to DFA state differences.
Not familiar with the scheduler enough to propose a fix, either it could be to
change handling of debug insns so that they never themselves start a new
scheduling tick, even if it would mean putting them after insns that want to be
last in the cycle, or do some changes in the DFA state saving/restoring.
