https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #10 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- Created attachment 55189 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55189&action=edit Proposed patch for postreload.cc so analysis is not bypassing "next" insn. (In reply to Georg-Johann Lay from comment #9) > postreload.cc::reload_cse_move2add() loops over all insns, and at some point > it encounters > > (insn 44 14 15 2 (set (reg/f:HI 14 r14 [58]) > (reg/v/f:HI 16 r16 [orig:51 self ] [51])) "fail1.c":28:5 101 > {*movhi_split} > (nil)) > > During the analysis for that insn, it executes > > rtx_insn *next = next_nonnote_nondebug_insn (insn); > rtx set = NULL_RTX; > if (next) > set = single_set (next); > > where next is > > (insn 15 44 16 2 (parallel [ > (set (reg/f:HI 14 r14 [58]) > (plus:HI (reg/f:HI 14 r14 [58]) > (const_int 68 [0x44]))) > (clobber (reg:QI 31 r31)) > ]) "fail1.c":28:5 175 {addhi3_clobber} > (nil)) > > Further down, it continues with success = 0: > > if (success) > delete_insn (insn); > changed |= success; > insn = next; > [...] > continue; > > The scan then continues with NEXT_INSN (insn), which is the insn AFTER insn > 15, so the CLOBBER of QI:31 in insn 15 is bypassed, and note_stores or > similar is never executed on insn 15. A simple solution is to not "insn = next;" and just to pseudo-delete insn so that NEXT_INSN (insn) works in the for loop: diff --git a/gcc/postreload.cc b/gcc/postreload.cc index fb392651e1b..388b8c0a506 100644 --- a/gcc/postreload.cc +++ b/gcc/postreload.cc @@ -2031,9 +2031,8 @@ reload_cse_move2add (rtx_insn *first) } } if (success) - delete_insn (insn); + SET_INSN_DELETED (insn); changed |= success; - insn = next; move2add_record_mode (reg); reg_offset[regno] = trunc_int_for_mode (added_offset + base_offset,
