https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94308
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:d5ad8ee04a78b576867fd78b2f25201ea6b4aae1 commit r10-7373-gd5ad8ee04a78b576867fd78b2f25201ea6b4aae1 Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Mar 25 11:40:00 2020 +0100 i386: Fix ix86_add_reg_usage_to_vzeroupper [PR94308] The following patch ICEs due to my recent change r10-6451-gb7b3378f91c. Since that patch, for explicit vzeroupper in the sources (when an intrinsic is used), we start with the *avx_vzeroupper_1 pattern which contains just the UNSPECV_VZEROUPPER and no sets/clobbers. The vzeroupper pass then adds some sets to those, but doesn't add clobbers and finally there is an && epilogue_completed splitter that splits this into the *avx_vzeroupper pattern which has the right number of sets/clobbers (16 on 64-bit, 8 on 32-bit) + the UNSPECV_VZEROUPPER first. The problem with this testcase on !TARGET_64BIT is that the vzeroupper pass adds 8 sets to the pattern, i.e. the maximum number, but INSN_CODE stays to be the one of the *avx_vzeroupper_1 pattern. The splitter doesn't do anything here, because it sees the number of rtxes in the PARALLEL already the right count, but during final we see that the *avx_vzeroupper_1 pattern has "#" output template and ICE that we forgot to split it. The following patch fixes it by forcing re-recognition of the insn after we make the changes to it in ix86_add_reg_usage_to_vzeroupper. Anything that will call recog_memoized later on will recog it and find out it is in this case already *avx_vzeroupper rather than *avx_vzeroupper_1. 2020-03-25 Jakub Jelinek <ja...@redhat.com> PR target/94308 * config/i386/i386-features.c (ix86_add_reg_usage_to_vzeroupper): Set INSN_CODE (insn) to -1 when changing the pattern. * gcc.target/i386/pr94308.c: New test.
