https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-9 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:b7cbce7a174292adc7c9d6db81bba6922a591d69 commit r9-8223-gb7cbce7a174292adc7c9d6db81bba6922a591d69 Author: Jakub Jelinek <ja...@redhat.com> Date: Mon Feb 10 22:44:40 2020 +0100 i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637] As mentioned in the PR, for -mavx -mno-avx2 the backend does support vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors aren't much supported in that case, it is performed using vandps/vandnps/vorps). The problem is that after the last generic vector lowering (where the VEC_COND_EXPR still compares two V4DF vectors and has two V4DI last operands and V4DI result and so is considered ok) fre4 folds the condition into constant, at which point the middle-end during expansion will try vcond_mask_optab and fall back to trying to expand it as the constant vector < 0 vcondv4div4di, but neither of them is supported for -mavx -mno-avx2 and thus we ICE. So, the options I see is either what the following patch does, also support vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current TARGET_AVX. 2020-02-10 Jakub Jelinek <ja...@redhat.com> PR target/93637 * config/i386/sse.md (VI_256_AVX2): New mode iterator. (vcond_mask_<mode><sseintvecmodelower>): Use it instead of VI_256. Change condition from TARGET_AVX2 to TARGET_AVX. * gcc.target/i386/avx-pr93637.c: New test.
