https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78342
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-11-21
CC| |jakub at gcc dot gnu.org,
| |segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd say the bug is in combine, which turns:
(insn 58 78 109 6 (set (reg:SI 178 [ r2+-3 ])
(const_int 1 [0x1])) "pr78342.c":23 373 {*movsi_internal1}
(nil))
(insn 109 58 61 6 (trap_if (eq (reg:SI 178 [ r2+-3 ])
(const_int 1 [0x1]))
(const_int 0 [0])) -1
(expr_list:REG_DEAD (reg:SI 178 [ r2+-3 ])
(nil)))
;; succ: 7 [100.0%] (FALLTHRU)
into:
(note 58 78 109 6 NOTE_INSN_DELETED)
(insn 109 58 61 6 (trap_if (const_int 1 [0x1])
(const_int 0 [0])) 602 {trap}
(nil))
;; succ: 7 [100.0%] (FALLTHRU)
While trap_if (something other than const1_rtx) is considered normal insn,
trap_if (const1_rtx) is considered a noreturn insn like noreturn call, that has
to terminate a bb. So I think what is wrong is that the corresponding bb still
has a successor, that edge should have been removed and cfg cleaned up.
Possibly if the bb contains conditional trap_if in the middle of the bb and
combiner changes it, we should also split the bb. Are there any other RTL
passes that turn conditional trap_if into unconditional?
