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?