https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
--- Comment #6 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:57e276f3e304ef92483763ee1028e5b3e1345e0f commit r9-8473-g57e276f3e304ef92483763ee1028e5b3e1345e0f Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Apr 7 21:00:28 2020 +0200 Fix vextract* masked patterns [PR93069] The AVX512F documentation clearly states that in instructions where the destination is a memory only merging-masking is possible, not zero-masking, and the assembler enforces that. The testcase in this patch fails to assemble because of Error: unsupported masking for `vextracti32x8' on vextracti32x8 $0x0, %zmm1, -64(%rsp){%k1}{z} For the vector extraction patterns, we apparently have 7 *_maskm patterns that only accept memory destinations and rtx_equal_p merge-masking source for it, 7 *<mask_name> corresponding patterns that allow memory destination only for the non-masked cases (through <store_mask_constraint>), then 2 *<mask_name> patterns (lo ssehalf V16FI and lo ssehalf VI8F_256 ones) which do allow memory destination even for masked cases and are the cause of the testsuite failure, because we must not allow C constraint if the destination is m, and finally one pair of patterns (separate * and *_mask, hi ssehalf VI4F_256), which has another issue (for which I don't have a testcase though), where if it would match zero-masking with register destination, it wouldn't emit the needed {z} into assembly. The attached patch fixes those 3 issues only, perhaps more suitable for backporting. 2020-03-30 Jakub Jelinek <ja...@redhat.com> PR target/93069 * config/i386/sse.md (vec_extract_lo_<mode><mask_name>): Use <store_mask_constraint> instead of m in output operand constraint. (vec_extract_hi_<mode><mask_name>): Use <mask_operand2> instead of %{%3%}. * gcc.target/i386/avx512vl-pr93069.c: New test. * gcc.dg/vect/pr93069.c: New test.
