https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
--- Comment #8 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #7) > The above testcase reproduced, reduced to following, started with r266385. > Note, this testcase ICEd in gcc 7.x and earlier too, got fixed with r258504 > (started with r225484). So, this testcase is effectively [7/9 Regression]. I looked at this. It is a typical problem for x86/x86-64 for some cases when the 1st insn scheduling is used. LRA in some cases can do hard register live range splitting to avoid such problems. The older reload even did not try to do thus. Sometimes LRA tries hard to do the range splitting which results in 'Maximum number of LRA assignment passes is achieved' failure. Unfortunately, the current hard reg live range splitting is not a panacea. I don't know how to make it working in for all cases. I believe the only sane solution for now is to switch off the 1st insn scheduler for problematic targets *even if user specifies -fschedule-insns*. It would stop permanent supply of the same problem especially by automatic test generators.
