This is the mail archive of the
mailing list for the GCC project.
ICE in gcc.dg/pr77834.c test for MIPS
- From: Toma Tabacu <Toma dot Tabacu at imgtec dot com>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Date: Thu, 16 Feb 2017 14:39:12 +0000
- Subject: ICE in gcc.dg/pr77834.c test for MIPS
- Authentication-results: sourceware.org; auth=none
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
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;
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.