[Bug rtl-optimization/91161] [9/10 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|9.3 |9.4

--- Comment #4 from Jakub Jelinek  ---
GCC 9.3.0 has been released, adjusting target milestone.

[Bug rtl-optimization/91161] [9/10 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
Yea, I think a NOTE_INSN_DELETED is valid in that location.  So yea, using
NEXT_INSN is probably wrong and we should be using something else  like
next_nonnote_insn.  My only worry with next_nonnote_insn would be if it skipped
something like a block note.  What would be the implications for the scheduler
if it walked through the various note insns?

[Bug rtl-optimization/91161] [9/10 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|9.2 |9.3

--- Comment #2 from Jakub Jelinek  ---
GCC 9.2 has been released.

[Bug rtl-optimization/91161] [9/10 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Priority|P3  |P2
Summary|[10 Regression] ICE in  |[9/10 Regression] ICE in
   |begin_move_insn, at |begin_move_insn, at
   |sched-ebb.c:175 |sched-ebb.c:175

[Bug rtl-optimization/91161] [9/10 Regression] ICE in begin_move_insn, at sched-ebb.c:175

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
With -fno-dce, a NOTE_INSN_DELETED_LABEL appears between the last "real" insn
in the basic block (a sibcall) and a barrier rtx:

(call_insn/u/c 20 19 12 3 (call (mem:QI (symbol_ref:DI ("ni") [flags 0x3] 
) [0 ni S1 A8])
(const_int 0 [0])) "pr91161.c":23:7 679 {*call}
 (expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:QI 0 ax)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("ni") [flags 0x3] 
)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list (use (reg:QI 0 ax))
(expr_list:DI (use (reg:DI 5 di))
(nil
(note 12 20 21 ("x6") NOTE_INSN_DELETED_LABEL 5)
(barrier 21 12 22)


Is this valid? I assume NOTE_INSN_DELETED can appear in that position as well?
If so, shouldn't begin_move_insn use next_nonnote_insn rather than plain
NEXT_INSN to find either the barrier or the label of the next bb?