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?

Reply via email to