https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127225
--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by hongtao Liu <[email protected]>: https://gcc.gnu.org/g:919c0d16c91c930c374db6665f55595653511636 commit r17-4017-g919c0d16c91c930c374db6665f55595653511636 Author: liuhongt <[email protected]> Date: Sun Sep 6 23:10:43 2026 -0700 i386: Fix unrecognizable V2SF zero move in V4SF vec_init [PR127225] With -mno-sse2 -mno-mmx -mno-3dnow, TARGET_SSE is still on but both TARGET_MMX and TARGET_MMX_WITH_SSE (TARGET_64BIT && TARGET_SSE2) are off, so there is no movv2sf expander even though *vec_concatv2sf_sse (TARGET_SSE) can still create V2SFmode pseudos. The !TARGET_SSE2 arm of ix86_expand_vector_init_v4sf materialized the zero upper half with a raw emit_insn (gen_rtx_SET (...)), which bypasses the emit_move_insn_1 fallback of moving via the same-sized integer mode, and so left behind (set (reg:V2SF 107) (const_vector:V2SF [(const_double:SF 0.0) x2])) for extract_insn to choke on. Use emit_move_insn instead; the zero then comes out as a DImode move and the sequence is the xorps/unpcklps/movlhps one GCC 16 emitted for this case. gcc/ChangeLog: PR target/127225 * config/i386/i386-expand.cc (ix86_expand_vector_init_v4sf): Use emit_move_insn rather than a bare SET to materialize the V2SFmode zero half, as movv2sf may not be available. gcc/testsuite/ChangeLog: PR target/127225 * gcc.target/i386/pr127225.c: New test.
