[Bug target/102140] New: [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

[Bug target/102140] New: [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

[zsojka at seznam dot cz]

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

            Bug ID: 102140
           Summary: [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
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: powerpc64le-unknown-linux-gnu

Created attachment 51385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51385&action=edit
reduced testcase

Compiler output:
$ powerpc64le-unknown-linux-gnu-gcc -Og -fipa-cp -fno-tree-ccp -fno-tree-ter
testcase.c
testcase.c: In function 'foo':
testcase.c:23:15: warning: integer constant is so large that it is unsigned
   23 |   bar (1, (V){9223372036854775808 << 64});
      |               ^~~~~~~~~~~~~~~~~~~
testcase.c: In function 'bar':
testcase.c:7:1: warning: GCC vector passed by reference: non-standard ABI
extension with no compatibility guarantee [-Wpsabi]
    7 | bar (char c, V v)
      | ^~~
testcase.c: In function 'bar.constprop':
testcase.c:18:1: error: insn does not satisfy its constraints:
   18 | }
      | ^
(insn 16 14 17 2 (set (reg:V4SI 65 1 [orig:120 _14 ] [120])
        (const_vector:V4SI [
                (const_int 0 [0]) repeated x3
                (const_int -2147483648 [0xffffffff80000000])
            ])) 1163 {vsx_movv4si_64bit}
     (expr_list:REG_EQUIV (const_vector:V4SI [
                (const_int 0 [0]) repeated x3
                (const_int -2147483648 [0xffffffff80000000])
            ])
        (nil)))
during RTL pass: reload
testcase.c:18:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x6defa8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        /repo/gcc-trunk/gcc/rtl-error.c:108
0x6df035 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        /repo/gcc-trunk/gcc/rtl-error.c:118
0x6cfb93 extract_constrain_insn(rtx_insn*)
        /repo/gcc-trunk/gcc/recog.c:2670
0xdad094 check_rtl
        /repo/gcc-trunk/gcc/lra.c:2087
0xdb20bc lra(_IO_FILE*)
        /repo/gcc-trunk/gcc/lra.c:2505
0xd63f59 do_reload
        /repo/gcc-trunk/gcc/ira.c:5932
0xd63f59 execute
        /repo/gcc-trunk/gcc/ira.c:6118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-3241-20210831093846-gd904008df26-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/12.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-3241-20210831093846-gd904008df26-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210831 (experimental) (GCC)

[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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
               Host|x86_64-pc-linux-gnu         |
      Known to work|                            |11.2.0
   Last reconfirmed|                            |2021-08-31
             Target|powerpc64le-unknown-linux-g |
                   |nu                          |

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed, most likely caused by r12-3072.

[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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |UNCONFIRMED
   Target Milestone|12.0                        |---
             Target|                            |powerpc64le-unknown-linux-g
                   |                            |nu
     Ever confirmed|1                           |0
      Known to work|11.2.0                      |

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Whoops wrong bug.

[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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

[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]

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).

[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

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Confirmed.  Doesn't need -mlittle or -mabi=elfv2, or -mcpu=power8 even, but
does need -mvsx.

[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]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52374&action=edit
gcc12-pr102140.patch

Untested fix.

[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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0c3e491a4e5ae74bfbed6d167d403d262b5a4adc

commit r12-7111-g0c3e491a4e5ae74bfbed6d167d403d262b5a4adc
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 8 20:14:30 2022 +0100

    rs6000: Fix up vspltis_shifted [PR102140]

    The following testcase ICEs, because
    (const_vector:V4SI [
                    (const_int 0 [0]) repeated x3
                    (const_int -2147483648 [0xffffffff80000000])
                ])
    is recognized as valid easy_vector_constant in between split1 pass and
    end of RA.
    The problem is that such constants need to be split, and the only
    splitter for that is:
    (define_split
      [(set (match_operand:VM 0 "altivec_register_operand")
            (match_operand:VM 1 "easy_vector_constant_vsldoi"))]
      "VECTOR_UNIT_ALTIVEC_OR_VSX_P (<MODE>mode) && can_create_pseudo_p ()"
    There is only a single splitting pass before RA, so after that finishes,
    if something gets matched in between that and end of RA (after that
    can_create_pseudo_p () would be no longer true), it will never be
    successfully split and we ICE at final.cc time or earlier.

    The i386 backend (and a few others) already use
    (cfun->curr_properties & PROP_rtl_split_insns)
    as a test for split1 pass finished, so that some insns that should be split
    during split1 and shouldn't be matched afterwards are properly guarded.

    So, the following patch does that for vspltis_shifted too.

    2022-02-08  Jakub Jelinek  <jakub@redhat.com>

            PR target/102140
            * config/rs6000/rs6000.cc (vspltis_shifted): Return false also if
            split1 pass has finished already.

            * gcc.dg/pr102140.c: New test.

[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]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:bc87b6d859941794072c5a970174d22466eca33d

commit r11-9600-gbc87b6d859941794072c5a970174d22466eca33d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 8 20:14:30 2022 +0100

    rs6000: Fix up vspltis_shifted [PR102140]

    The following testcase ICEs, because
    (const_vector:V4SI [
                    (const_int 0 [0]) repeated x3
                    (const_int -2147483648 [0xffffffff80000000])
                ])
    is recognized as valid easy_vector_constant in between split1 pass and
    end of RA.
    The problem is that such constants need to be split, and the only
    splitter for that is:
    (define_split
      [(set (match_operand:VM 0 "altivec_register_operand")
            (match_operand:VM 1 "easy_vector_constant_vsldoi"))]
      "VECTOR_UNIT_ALTIVEC_OR_VSX_P (<MODE>mode) && can_create_pseudo_p ()"
    There is only a single splitting pass before RA, so after that finishes,
    if something gets matched in between that and end of RA (after that
    can_create_pseudo_p () would be no longer true), it will never be
    successfully split and we ICE at final.cc time or earlier.

    The i386 backend (and a few others) already use
    (cfun->curr_properties & PROP_rtl_split_insns)
    as a test for split1 pass finished, so that some insns that should be split
    during split1 and shouldn't be matched afterwards are properly guarded.

    So, the following patch does that for vspltis_shifted too.

    2022-02-08  Jakub Jelinek  <jakub@redhat.com>

            PR target/102140
            * config/rs6000/rs6000.c (vspltis_shifted): Return false also if
            split1 pass has finished already.

            * gcc.dg/pr102140.c: New test.

    (cherry picked from commit 0c3e491a4e5ae74bfbed6d167d403d262b5a4adc)

[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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:df8a6a1fcab38b9e4c5bcb8b9a39f847c18e9026

commit r10-10675-gdf8a6a1fcab38b9e4c5bcb8b9a39f847c18e9026
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 8 20:14:30 2022 +0100

    rs6000: Fix up vspltis_shifted [PR102140]

    The following testcase ICEs, because
    (const_vector:V4SI [
                    (const_int 0 [0]) repeated x3
                    (const_int -2147483648 [0xffffffff80000000])
                ])
    is recognized as valid easy_vector_constant in between split1 pass and
    end of RA.
    The problem is that such constants need to be split, and the only
    splitter for that is:
    (define_split
      [(set (match_operand:VM 0 "altivec_register_operand")
            (match_operand:VM 1 "easy_vector_constant_vsldoi"))]
      "VECTOR_UNIT_ALTIVEC_OR_VSX_P (<MODE>mode) && can_create_pseudo_p ()"
    There is only a single splitting pass before RA, so after that finishes,
    if something gets matched in between that and end of RA (after that
    can_create_pseudo_p () would be no longer true), it will never be
    successfully split and we ICE at final.cc time or earlier.

    The i386 backend (and a few others) already use
    (cfun->curr_properties & PROP_rtl_split_insns)
    as a test for split1 pass finished, so that some insns that should be split
    during split1 and shouldn't be matched afterwards are properly guarded.

    So, the following patch does that for vspltis_shifted too.

    2022-02-08  Jakub Jelinek  <jakub@redhat.com>

            PR target/102140
            * config/rs6000/rs6000.c (vspltis_shifted): Return false also if
            split1 pass has finished already.

            * gcc.dg/pr102140.c: New test.

    (cherry picked from commit 0c3e491a4e5ae74bfbed6d167d403d262b5a4adc)

[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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:8c9f4bafe532508904d4d16379d6882ddedac367

commit r9-10123-g8c9f4bafe532508904d4d16379d6882ddedac367
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 8 20:14:30 2022 +0100

    rs6000: Fix up vspltis_shifted [PR102140]

    The following testcase ICEs, because
    (const_vector:V4SI [
                    (const_int 0 [0]) repeated x3
                    (const_int -2147483648 [0xffffffff80000000])
                ])
    is recognized as valid easy_vector_constant in between split1 pass and
    end of RA.
    The problem is that such constants need to be split, and the only
    splitter for that is:
    (define_split
      [(set (match_operand:VM 0 "altivec_register_operand")
            (match_operand:VM 1 "easy_vector_constant_vsldoi"))]
      "VECTOR_UNIT_ALTIVEC_OR_VSX_P (<MODE>mode) && can_create_pseudo_p ()"
    There is only a single splitting pass before RA, so after that finishes,
    if something gets matched in between that and end of RA (after that
    can_create_pseudo_p () would be no longer true), it will never be
    successfully split and we ICE at final.cc time or earlier.

    The i386 backend (and a few others) already use
    (cfun->curr_properties & PROP_rtl_split_insns)
    as a test for split1 pass finished, so that some insns that should be split
    during split1 and shouldn't be matched afterwards are properly guarded.

    So, the following patch does that for vspltis_shifted too.

    2022-02-08  Jakub Jelinek  <jakub@redhat.com>

            PR target/102140
            * config/rs6000/rs6000.c (vspltis_shifted): Return false also if
            split1 pass has finished already.

            * gcc.dg/pr102140.c: New test.

    (cherry picked from commit 0c3e491a4e5ae74bfbed6d167d403d262b5a4adc)