This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hello,

I have been looking into an ICE triggered by the gcc.dg/pr77834.c test for
MIPS targets (filed as PR 79150).

It turns out that it is unrelated to the fix for PR 77834, as the code from the
test case triggers the same ICE even without those changes.

It is caused by "gcc_assert (!JUMP_P (last))" in
commit_one_edge_insertion (gcc/cfgrtl.c:2059-2077):

  if (returnjump_p (last))
    {
      /* ??? Remove all outgoing edges from BB and add one for EXIT.
	 This is not currently a problem because this only happens
	 for the (single) epilogue, which already has a fallthru edge
	 to EXIT.  */

      e = single_succ_edge (bb);
      gcc_assert (e->dest == EXIT_BLOCK_PTR_FOR_FN (cfun)
		  && single_succ_p (bb) && (e->flags & EDGE_FALLTHRU));

      e->flags &= ~EDGE_FALLTHRU;
      emit_barrier_after (last);

      if (before)
	delete_insn (before);
    }
  else
    gcc_assert (!JUMP_P (last));

The test case uses the vector_size __attribute__ to define a vector type.

The trouble starts in insert_partition_copy_on_edge (gcc/tree-outof-ssa.c:239),
which calls emit_partition_copy. For vectors of vector_size >=32,
emit_partition_copy will call emit_block_move which will eventually end up
calling mips_expand_block_move (gcc/config/mips.c:8103), which generates a
looped block move for a vector_size >32 for MIPS32 or >64 for MIPS64.

Fast-forwarding to commit_one_edge_insertion, if an edge has a looped block move,
"last" will point to the conditional jump_insn from the looped block move,
which will fail the "returnjump_p (last)" condition and, because it is a
jump_insn, it will trigger the "!JUMP_P (last)" assert.

I can't come up with a reason for this assert and this code hasn't been touched
in a long time, so I'm not sure it's necessary. It looks to me like it was
added more out of habit rather than for a specific reason.

I ran the testsuite (only for the MIPS target and only GCC tests) without the
problematic assert and there were no extra failures.

I would be grateful for any help with this.

Regards,
Toma Tabacu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]