ICE in gcc.dg/pr77834.c test for MIPS

[Segher Boessenkool]

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