On Mon, Jul 13, 2009 at 11:46 PM, Kaz Kojima<kkoj...@rr.iij4u.or.jp> wrote: > Hi, > > I hope DF/middle-end experts will comment about this. > > PR target/40710 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40710 > > is a wrong code problem on SH. A delayed slot of a conditional > branch insn is wrongly filled with an insn changing stack pointer > in the failing case. I've tried to see what is going on.
You found out why the dbr-sched pass (reorg.c) needs a rewrite so badly. DF needs a CFG, and reorg.c refuses to maintain a valid CFG. In other words, it just doesn't work very well together. See PR39938, PR40086, etc... Basically, as long as on-one is willing to put up the resources to beat sense into reorg.c, you'll probably continue to find bugs related to delay slot filling. Anyway, the bug here is probably somewhere between .compgotos and reorg, because from your dump we have: ;; Start of basic block ( 0) -> 2 ;; live in 4 [r4] 5 [r5] 6 [r6] 146 [pr] ;; live out 1 [r1] 2 [r2] 3 [r3] 4 [r4] 5 [r5] 6 [r6] 15 [r15] ;; Start of basic block ( 2) -> 3 ;; live in 1 [r1] 2 [r2] 4 [r4] 5 [r5] 6 [r6] 15 [r15] ;; live out 1 [r1] 2 [r2] 4 [r4] 5 [r5] 6 [r6] 7 [r7] 15 [r15] So when the CFG is still valid, r15 is live-out in basic block 2 and live-in in basic block 3 (which contains insns 32, whatever that means for an invalid CFG). For which bb does mark_target_live_regs call df_get_live_in? Ciao! Steven
