https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98849
--- Comment #13 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:e7429bc9d60c0cb9809a8040bb63dbb9390f40f1 commit r11-6970-ge7429bc9d60c0cb9809a8040bb63dbb9390f40f1 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri Jan 29 11:54:22 2021 +0100 arm: Fix up -mcpu=iwmmxt ICEs [PR98849] The https://gcc.gnu.org/r11-6707-g7432f255b70811dafaf325d94036ac580891de69 https://gcc.gnu.org/r11-6708-gbfab355012ca0f5219da8beb04f2fdaf757d34b7 changes moved the vashl/vashr/vlshr expanders from neon.md to vec-common.md and changed their condition from TARGET_NEON to ARM_HAVE_<MODE>_ARITH, so that they apply also for TARGET_HAVE_MVE. But, the ARM_HAVE_<MODE>_ARITH macros are sometimes true also for TARGET_REALLY_IWMMXT, which at least from quick skimming of former iwmmxt*.md doesn't have such instructions, so it seems incorrect to enable them for iwmmxt. Furthermore, even if it had them, iwmmxt doesn't support any way to broadcast values in those modes (vec_duplicate and vec_init optabs) and the middle end relies on if the vector x vector shift/rotate patterns are supported it can emit vector x scalar shift/rotate by broadcasting the shift amount to a vector. As the TARGET_NEON vs. TARGET_REALLY_IWMMXT vs. TARGET_HAVE_MVE never seem to be enabled together, I think we can just write it the following way. Note, seems iwmmxt actually does support vector x scalar shifts, but doesn't really enable the optabs that would tell the middle-end code that it does (and neon and mve don't seem to support those). I'll defer that to anybody that cares about iwmmxt (if any). 2021-01-29 Jakub Jelinek <ja...@redhat.com> PR target/98849 * config/arm/vec-common.md (mve_vshlq_<supf><mode>, vashl<mode>3, vashr<mode>3, vlshr<mode>3): Add && !TARGET_REALLY_IWMMXT to conditions. * gcc.c-torture/compile/pr98849.c: New test.
