This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 07 Nov 2012 11:28:13 +0000
- Subject: [Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
- Auto-submitted: auto-generated
- References: <bug-55153-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-07 11:28:13 UTC ---
I've tried to "fix" this similarly to PR48721:
--- sched-deps.c.jj2 2012-10-17 17:18:21.000000000 +0200
+++ sched-deps.c 2012-11-07 12:15:05.246124552 +0100
@@ -2907,7 +2907,10 @@ sched_analyze_insn (struct deps_desc *de
{
rtx next;
next = next_nonnote_nondebug_insn (insn);
- if (next && BARRIER_P (next))
+ /* Don't schedule anything after an unconditional return jump. */
+ if (returnjump_p (insn) && ! condjump_p (insn))
+ reg_pending_barrier = TRUE_BARRIER;
+ else if (next && BARRIER_P (next))
reg_pending_barrier = MOVE_BARRIER;
else
{
but that didn't help. The difference between reload and LRA seems to be just
in that old reload emitted a deleted note after the prefetch for some reason,
and after adding simple_return jump and barrier after it that note was still
following the barrier, while with LRA there is no such deleted note at the end.
Still the scheduler seems to attempt to do DCE of the prefetch (why? Isn't the
prefetch meaningful on its own?). Vlad, can you please have a look? Thanks.