On Thu, Feb 23, 2017 at 10:43:36PM +0000, Matthew Fortune wrote: > This is an ICE that will be reproducible on a primary target so is still > appropriate to pursue in stage4 as far as I understand. I'm hoping to > find time to work with Toma on this issue.
Ah. Is there a PR for it yet? Please open one, if not. > > Can't whatever creates those jump insns keep the cfg in shape? That > > would avoid all issues here. > > The problem, I think, is that these instructions are not yet in the cfg > and are being inserted on an edge. The jump is produced from the inline > memcpy expansion we do for MIPS. So this is generated during expand? I don't see how it ends up on an edge. > In some cases there will be no loop, > some cases there will be a loop ending with the conditional jump and > some cases will have a loop and other instructions after the conditional > jump. The 1st and 3rd form will get through the logic in > commit_one_edge_insertion (albeit that the 3rd form will have incorrect > cfg actually) but the 2nd form is rejected because of ending with a jump. You can easily turn the 2nd form into the 3rd by emitting some no-op instruction last. If you can live with 3rd for GCC 7, that may be a good solution for now. > Other than coping with the potential for sub blocks here or letting them > through and leaving later code to split the blocks then I see no other > way forward. I agree it should be possible to process just the blocks > with jump instructions in the middle and that is actually going to be > exactly one block in this case. I don't know if updating the CFG while > edges are being iterated on in commit_edge_insertions is safe though > and am somewhat out of my comfort zone in general! Yeah I'm really not seeing where/when your movmem is emitted. Segher
