https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89765
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- The ICE started with r262946. Short testcase reproduceable with a cross to powerpc64le-linux with -maltivec -mvsx -O1: typedef unsigned __int128 V __attribute__((vector_size (sizeof (__int128)))); V foo (unsigned __int128 x, V y, int z) { return __builtin_vec_insert (x, y, z); } During gimplification, gimplify_expr does: 12577 *expr_p = fold_indirect_ref_loc (input_location, *expr_p); 12578 if (*expr_p != save_expr) 12579 { 12580 ret = GS_OK; 12581 break; 12582 } 12583 12584 ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p, post_p, 12585 is_gimple_reg, fb_rvalue); 12586 if (ret == GS_ERROR) 12587 break; on *expr_p: <indirect_ref 0x7fffea99d260 type <integer_type 0x7fffea7f7bd0 __int128 unsigned public unsigned TI size <integer_cst 0x7fffea805018 constant 128> unit-size <integer_cst 0x7fffea805030 constant 16> align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea7f7bd0 precision:128 min <integer_cst 0x7fffea805300 0> max <integer_cst 0x7fffea806028 0xffffffffffffffffffffffffffffffff> pointer_to_this <pointer_type 0x7fffea983f18>> side-effects arg:0 <nop_expr 0x7fffea99d200 type <pointer_type 0x7fffea983f18 type <integer_type 0x7fffea7f7bd0 __int128 unsigned> unsigned DI size <integer_cst 0x7fffea7f4fc0 constant 64> unit-size <integer_cst 0x7fffea7f4fd8 constant 8> align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea983f18> side-effects arg:0 <addr_expr 0x7fffea99d1e0 type <pointer_type 0x7fffea983c78> side-effects arg:0 <compound_literal_expr 0x7fffea99d1c0 type <vector_type 0x7fffea983d20 V> side-effects addressable arg:0 <decl_expr 0x7fffea99d1a0 type <vector_type 0x7fffea983d20 V> side-effects arg:0 <var_decl 0x7ffff7ffb3f0 D.2833> pr89765.i:6:10 start: pr89765.i:6:10 finish: pr89765.i:6:29>> pr89765.i:6:10 start: pr89765.i:6:10 finish: pr89765.i:6:29> pr89765.i:6:10 start: pr89765.i:6:10 finish: pr89765.i:6:29> pr89765.i:6:10 start: pr89765.i:6:10 finish: pr89765.i:6:29> fold_indirect_ref_1 has for this: 14205 else if (VECTOR_TYPE_P (optype) 14206 && type == TREE_TYPE (optype)) 14207 { 14208 tree part_width = TYPE_SIZE (type); 14209 tree index = bitsize_int (0); 14210 return fold_build3_loc (loc, BIT_FIELD_REF, type, op, part_width, 14211 index); 14212 } but match.pd actually folds that into a VIEW_CONVERT_EXPR and we keep it at the lhs and ICE during checking. Without the match.pd change, we used to have: D.2803 = y_2(D); BIT_FIELD_REF <D.2803, 128, 0> = x_4(D); _6 = D.2803; even in ssa pass and only ccp1 changed that into: _7 = y_2(D); _8 = BIT_INSERT_EXPR <_7, x_4(D), 0 (128 bits)>; _6 = _8; Now we ICE already during gimple pass verification. Shall we special case VIEW_CONVERT_EXPR on lhs of assignment by moving the VCE to the rhs instead? Something different?