https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126512
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by jeevitha <[email protected]>: https://gcc.gnu.org/g:8edcb1d9fbc204cb87598cddb94cc85e99b4e189 commit r17-3697-g8edcb1d9fbc204cb87598cddb94cc85e99b4e189 Author: Manjunath S Matti <[email protected]> Date: Sun Aug 23 10:38:02 2026 -0500 rs6000: Fix ICE with __int128 vector built-ins and -mno-vsx [PR126512] The changes have been bootstrapped and regression tested on powerpc64le-linux and powerpc64-linux. V1TImode is only enabled when TARGET_VSX is set (see rs6000_init_hard_regno_mode_ok, where rs6000_vector_mem[V1TImode] and rs6000_vector_unit[V1TImode] are only set up under TARGET_VSX). Consequently rs6000_vector_mode_supported_p returns false for V1TImode with -mno-vsx, and vector_type_mode () demotes the "vector __int128" types to plain TImode. Moving these built-ins to the [vsx] stanza so they are gated on TARGET_VSX, which is where the corresponding V2DF/V2DI vperm/vsel/vsldoi built-ins already live. We then emit a proper diagnostic instead of ICEing, similar to PR109932 was fixed for __builtin_pack_vector_int128: vec_perm and vec_sld on __int128 vectors ICEd in exactly the same way and are fixed by the same change. __builtin_altivec_lvx_v1ti is deliberately left in [altivec]: it goes through ldv_expand_builtin () rather than the generic path, does not ICE, and produces semantically correct code with -mno-vsx. 2026-08-23 Manjunath Matti <[email protected]> gcc/ChangeLog: PR target/126512 * config/rs6000/rs6000-builtins.def (__builtin_altivec_vperm_1ti, __builtin_altivec_vperm_1ti_uns, __builtin_altivec_vsel_1ti, __builtin_altivec_vsel_1ti_uns, __builtin_altivec_vsldoi_v1ti): Move from the [altivec] stanza to the [vsx] stanza. gcc/testsuite/ChangeLog: PR target/126512 * gcc.target/powerpc/pr126512.c: New test.
