https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040
--- Comment #3 from Roman Zhuykov <zhroma at gcc dot gnu.org> --- (In reply to Roman Zhuykov from comment #2) > Same ICE also appears when compiling gcc.c-torture/execute/pr71550.c with So, I've opened separate PR93264 for that example, and now we have some related discussion there. Another discussion was in mailing list, starting from https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00666.html > With my local (still WIP) modulo-sched features, SMS pass can be used on > x86, where -freorder-blocks-and-partition is enabled by default. So, this > assertion failure becomes much more annoying, even bootstrap failed on it in > some specific conditions. I've found some mistake in my patches. For testing purpose I've tried to make some extreme conditions for modulo-scheduler and modified the way loop_version is called. And that help me to find a way to make the latent issue more obvious. Imagine a scenario when modulo-sched.c code calls loop_version with always-true condition, e.q. get_rtx_GEU(left, right), where 'right' can eventually be a compile-time zero constant. It this situation there are a lot of tests on different platforms where problematic assertion failure appears as an ICE. It tries to redirect (with _force) a basic block, where last instruction is barrier, and the previous instruction is a fallthrough jump. After fixing my mistake the ICE doesn't impede further SMS enhancements.
