https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713
--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> --- It seems that one of the loop optimizations pulls the casesi_0 and casesi_worker_0 insns apart and then things go wrong from there on. Compiling the test case with -fno-move-loop-invariants results in the correct code. I guess the actual problem is that what the SH backend expands results in some unexpected/unhandled CFG for the case insn. One option could be to merge the casesi_0 and casesi_worker_0 / casesi_worker_1 patterns somehow into one pattern, so that the block remains in one place. Another option I can think of would be feeding the bounds check comparison result from the casesi_0 insns into casesi_worker_0/casesi_worker_1 and add a conditional branch around the table access.
