[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[andi-gcc at firstfloor dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

Andi Kleen  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Andi Kleen  ---
Long fixed.

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #8 from Arseny Solokha  ---
I believe this PR should be marked either RESOLVED FIXED or DUPLICATE of
PR80463.

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[abel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

--- Comment #6 from Andrey Belevantsev  ---
Author: abel
Date: Tue Mar 15 15:25:41 2016
New Revision: 234217

URL: https://gcc.gnu.org/viewcvs?rev=234217=gcc=rev
Log:
gcc/

PR rtl-optimization/63384
* sel-sched.c (invoke_aftermath_hooks): Do not decrease issue_more
on DEBUG_INSN_P insns.

testsuite/

PR rtl-optimization/63384
* g++.dg/pr63384.C: New test. 

Added:
trunk/gcc/testsuite/g++.dg/pr63384.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[abel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

Andrey Belevantsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-22
 Ever confirmed|0   |1

--- Comment #5 from Andrey Belevantsev  ---
We're looping because we decrease the counter of the insns we still can issue
(can_issue_more) on a DEBUG_INSN.  The following helps us to get away with it
but frankly I have no idea why it was not surfaced before -- no such insns with
usual debug info?

diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index c798935..893a3e5 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -4249,7 +4249,8 @@ invoke_aftermath_hooks (fence_t fence, rtx_insn
*best_insn, int issue_more)
   issue_more);
   memcpy (FENCE_STATE (fence), curr_state, dfa_state_size);
 }
-  else if (GET_CODE (PATTERN (best_insn)) != USE
+  else if (! DEBUG_INSN_P (best_insn)
+  && GET_CODE (PATTERN (best_insn)) != USE
&& GET_CODE (PATTERN (best_insn)) != CLOBBER)
 issue_more--;

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[andi-gcc at firstfloor dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384

--- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org ---
It loops forever in this loop in sel_sched_region_2

  while (fences)
{
  int min_seqno, max_seqno;
  ilist_t scheduled_insns = NULL;
  ilist_t *scheduled_insns_tailp = scheduled_insns;

  find_min_max_seqno (fences, min_seqno, max_seqno);
  schedule_on_fences (fences, max_seqno, scheduled_insns_tailp);
  fences = calculate_new_fences (fences, orig_max_seqno, max_time);
  highest_seqno_in_use = update_seqnos_and_stage (min_seqno, max_seqno,
  highest_seqno_in_use,
  scheduled_insns);
}

because calculate_new_fences always comes up with a list which is the same as
before. In move_fence_to_fences it always goes into the else

 f = flist_lookup (FLIST_TAIL_HEAD (new_fences),
FENCE_INSN (FLIST_FENCE (old_fences)));
  if (f)
{
  merge_fences (f, old-insn, old-state, old-dc, old-tc,
old-last_scheduled_insn, old-executing_insns,
old-ready_ticks, old-ready_ticks_size,
old-sched_next, old-cycle, old-issue_more,
old-after_stall_p);
}
  else
{
  _list_add (tailp);
  FLIST_TAIL_TAILP (new_fences) = FLIST_NEXT (*tailp);


So something is going wrong in flist_lookup.