[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Priority|P3                          |P1

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Slightly adjusted testcase, so that there is no warning about too large
constant:
typedef int __attribute__((__vector_size__ (64))) U;
typedef __int128 __attribute__((__vector_size__ (64))) V;

int a, b;

static void
bar (char c, V v)
{
  v *= c;
  U u = a + (U) v;
  (union { U b; }) { u };
  b = 0;
}

void
foo (void)
{
  bar (1, (V){((__int128) 9223372036854775808ULL) << 64});
}

Started with r12-139-g7d6bb80931b429631f63e0fd27bee95f32eb57a9 which was a
middle-end change, so I bet it just triggered a latent backend or LRA bug.

If I do:
typedef int V __attribute__((vector_size (16)));
typedef __int128 W __attribute__((vector_size (16)));

V
foo (void)
{
  return (V) (W) { (unsigned __int128) 1 << 127 };
}

V
bar (void)
{
  return (V) { 0, 0, 0, -__INT_MAX__ - 1 };
}

then the insns like:
(insn 9 5 10 2 (set (reg/i:V4SI 66 2)
        (const_vector:V4SI [
                (const_int 0 [0]) repeated x3
                (const_int -2147483648 [0xffffffff80000000])
            ])) "pr102140-3.c":8:1 1127 {vsx_movv4si_64bit}
     (expr_list:REG_EQUAL (const_vector:V4SI [
                (const_int 0 [0]) repeated x3
                (const_int -2147483648 [0xffffffff80000000])
            ])
        (nil)))
is split during split1.  But on the above testcase we have
(insn 10 7 12 2 (set (reg:TI 118 [ _12 ])
        (const_wide_int 0x80000000000000000000000000000000)) "pr102140.c":9:5
1134 {vsx_movti_64bit}
     (nil))
...
(insn 17 15 18 2 (set (reg:V4SI 120 [ _14 ])
        (subreg:V4SI (reg:TI 118 [ _12 ]) 0)) 1127 {vsx_movv4si_64bit}
     (expr_list:REG_DEAD (reg:TI 118 [ _12 ])
        (expr_list:REG_EQUAL (const_vector:V4SI [
                    (const_int 0 [0]) repeated x3
                    (const_int -2147483648 [0xffffffff80000000])
                ])
            (nil))))
during split1 and only IRA forward propagates the constant into the insn.
So perhaps the operand predicate shouldn't allow such constants after split1?
split1 pass sets PROP_rtl_split_insns property which e.g. the i386 backend is
using to make sure not to match stuff after split1 if it was only supposed to
be valid before split1 (see ix86_pre_reload_split predicate).