https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93611
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 47788 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47788&action=edit gcc10-pr93611.patch Ugh, this is nasty. The problem is that splitting works by clearing recog_data.insn and then performing various recog_data.operand elt changes, trying to match various splitters. That works fine, because if somebody does extract_insn_cached afterwards, it will not use cache and will extract it again. The problem is that two of the i386.md splitters have conditions that ultimately call extract_insn_cached, so if we are unlucky, try to match splitter with that condition (which sets recog_data.insn to the current instruction), that condition fails and we continue looking for further matching splitters, we modify recog_data.operand again, but the generated split_insns doesn't expect something modifies recog_data.insn. So, when after splitting some other pass performs extract_insn_cached, it can see a match, but recog_data.operand array contains garbage from the failed attempts to split, yet recog_data.insn says it is correct.
