This is the mail archive of the
mailing list for the GCC project.
Re: ICE in gcc.dg/pr77834.c test for MIPS
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
> 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.