[Bug rtl-optimization/85409] [8 Regression] ICE in alloc_succs_info, at sel-sched-ir.c:4730

2018-04-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85409

--- Comment #4 from Jakub Jelinek  ---
The general rule is that DEBUG_INSN_P should not affect code-gen related
decisions and the compiler needs to cope with them as best as it can when the
decisions have been made.  sel-sched already violates that though.  You could
have separate lookahead for non-debug and debug insns (or space in there),
though of course need to handle the case when there are really way too many
debug insns among very few other insns (you can have millions of debug insns
with no other insns in between in corner cases).

[Bug rtl-optimization/85409] [8 Regression] ICE in alloc_succs_info, at sel-sched-ir.c:4730

2018-04-16 Thread abel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85409

--- Comment #3 from Andrey Belevantsev  ---
This one is cool.  We hit an assert saying we cannot hold of successor info
anymore.  The succs vector size is of max_ws (maximum lookahead) + 1, but guess
what, there's a lot of debug insns and these are not counted against windowsize
when computing the availability set because of:

2949   if (DEBUG_INSN_P (last_insn))
2950 continue;
2951
2952   if (end_ws > max_ws)
2953 {
2954   /* We can reach max lookahead size at bb_header, so clean av_set
2955  first.  */
2956   INSN_WS_LEVEL (last_insn) = global_level;
2957
2958   if (sched_verbose >= 6)
2959 sel_print ("Insn %d is beyond the software lookahead window
size\n",
2960INSN_UID (last_insn));
2961   break;
2962 }
2963
2964   end_ws++;

Thoughts?

[Bug rtl-optimization/85409] [8 Regression] ICE in alloc_succs_info, at sel-sched-ir.c:4730

2018-04-16 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85409

--- Comment #2 from Arseny Solokha  ---
(In reply to Jakub Jelinek from comment #1)
> I've bisected it to r259231.

Interesting. I reduced it from a file I have since 8.0.0-alpha20180121 snapshot
timeframe, and the backtrace was the same back then.

[Bug rtl-optimization/85409] [8 Regression] ICE in alloc_succs_info, at sel-sched-ir.c:4730

2018-04-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85409

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Version|unknown |8.0
   Keywords|ice-on-invalid-code |ice-on-valid-code
   Last reconfirmed||2018-04-16
 CC||abel at gcc dot gnu.org,
   ||amonakov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in alloc_succs_info, at |[8 Regression] ICE in
   |sel-sched-ir.c:4730 |alloc_succs_info, at
   ||sel-sched-ir.c:4730
   Target Milestone|--- |8.0

--- Comment #1 from Jakub Jelinek  ---
With -m32 -mcpu=e300c3 -O1 -fselective-scheduling -fschedule-insns
-fvar-tracking-assignments
I've bisected it to r259231.  It requires explicit -fvar-tracking-assignments
people rarely use, so I think this doesn't deserve to be a P1.