On Sun, Nov 08, 2015 at 08:21:47PM -0700, Jeff Law wrote: > On 11/08/2015 08:09 PM, Segher Boessenkool wrote: > >The code mistakenly thinks any cond_jump has two successors. This is > >not true if both destinations are the same, as can happen with weird > >patterns as in the PR. > > > >Bootstrapped and tested on powerpc64-linux; also tested the simplified > >test in the PR on an x86_64-linux cross. > > > >Sorry for the breakage. Is this okay for trunk? > > > > > >Segher > > > > > >2015-11-09 Segher Boessenkool <seg...@kernel.crashing.org> > > > > * gcc/bb-reorder.c (reorder_basic_blocks_simple): Treat a conditional > > branch with only one successor just like unconditional branches. > OK. Though this begs the question, should something have cleaned that > up prior to bb-reorder?
It normally does (which I why I hadn't noticed it), but there is no unconditional version of this in the machine description. It seems to create a conditional branch so that it can do a move from a pseudo (that it sets in the branch pattern itself, it's a parallel) to the AX register. bb-reorder runs after RA so that move has been folded, the pseudo itself is in AX already, so both arms of the conditional now point to the next insn. I don't know why the backend cannot put AX directly in this pattern (or while expanding it). Either way, bb-reorder should be able to handle the situation. > Don't forget the PR marker in the committed ChangeLog. Uh yes, thanks. Segher
