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

[Segher Boessenkool]

Hi Toma,

On Thu, Feb 23, 2017 at 04:27:26PM +0000, Toma Tabacu wrote:
> > This happens when you have inserted code ending in a jump on an edge.
> > This then will need updating of the CFG, and this code does not know
> > how to do that.
> 
> Would the following be an appropriate solution ?

[ snip ]

> @@ -2047,6 +2047,16 @@ commit_one_edge_insertion (edge e)
> +  /* If the edge contains control flow instructions, remember to update the
> +     CFG after the insertion.  */

I don't know what all can break if you allow control flow insns in
insert_insn_on_edge -- this function is called from many different
passes, many things can break -- but this does look like it should work.

> +  bool update_cfg = false;
> +  for (tmp = insns; tmp && update_cfg == false; tmp = NEXT_INSN (tmp))
> +     if (control_flow_insn_p (tmp))
> +       {
> +	 update_cfg = true;
> +	 break;
> +       }

> +  if (update_cfg)
> +    {
> +      auto_sbitmap blocks (last_basic_block_for_fn (cfun));
> +      bitmap_ones (blocks);
> +      find_many_sub_basic_blocks (blocks);
> +
> +      last = BB_END (bb);
> +    }

Maybe you can keep track of what blocks to split, instead of just saying
"all".

> In short, I'm updating the CFG by calling find_many_sub_basic_blocks with an
> all-one block bitmap (this also happens in cfgexpand.c, after the edge
> insertions) whenever an edge contains an insn which satisfies control_flow_insn_p.

Can't whatever creates those jump insns keep the cfg in shape?  That
would avoid all issues here.

General...  Patches need to go to gcc-patches@.  You also should have
your copyright assignment in order (I have no idea if you do; if you
do, please ignore).  Finally, trunk currently is in stage 4, this work
will need to wait for stage 1 (a couple of months, something like that).


Segher