[Bug c++/105953] New: [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[Bug c++/105953] New: [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[gscfq@t-online.de]

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

            Bug ID: 105953
           Summary: [12/13 Regression] ICE in extract_insn, at
                    recog.cc:2791
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Started between 20211212 and 20211219,
with file g++.target/i386/pr100738-1.C :


$ g++-13-20220612 -c pr100738-1.C -O2 -mavx512vl -mabi=ms
pr100738-1.C: In function 'v4si foo_1(v16qi, v4si, v4si, v4si)':
pr100738-1.C:13:1: error: unrecognizable insn:
   13 | }
      | ^
(insn 28 27 21 2 (set (subreg:V16QI (reg:V4SI 84 [ <retval> ]) 0)
        (unspec:V16QI [
                (reg:V16QI 101)
                (mem/c:V16QI (reg:DI 100) [1 d+0 S16 A128])
                (subreg:V16QI (lt:V4SI (mem/c:V4SI (reg:DI 98) [0 a+0 S16
A128])
                        (const_vector:V4SI [
                                (const_int 0 [0]) repeated x4
                            ])) 0)
            ] UNSPEC_BLENDV)) "pr100738-1.C":12:31 -1
     (expr_list:REG_DEAD (reg:V16QI 101)
        (expr_list:REG_DEAD (reg:DI 100)
            (expr_list:REG_DEAD (reg:DI 98)
                (nil)))))
during RTL pass: ira
pr100738-1.C:13:1: internal compiler error: in extract_insn, at recog.cc:2791
0x698229 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ../../gcc/rtl-error.cc:108
0x698248 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../../gcc/rtl-error.cc:116
0xd24317 extract_insn(rtx_insn*)
        ../../gcc/recog.cc:2791
0xbe6c10 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
        ../../gcc/ira.cc:5356
0xbe78f5 remove_scratches
        ../../gcc/ira.cc:5400
0xbe78f5 ira
        ../../gcc/ira.cc:5724
0xbe78f5 execute
        ../../gcc/ira.cc:6083

[Bug target/105953] [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-06-14
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Target Milestone|---                         |12.3
                 CC|                            |liuhongt at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Instruction does not accept memory operand for operand 3:

(define_insn_and_split
"*<sse4_1>_blendv<ssefltmodesuffix><avxsizesuffix>_ltint"
  [(set (match_operand:<ssebytemode> 0 "register_operand" "=Yr,*x,x")
        (unspec:<ssebytemode>
          [(match_operand:<ssebytemode> 1 "register_operand" "0,0,x")
           (match_operand:<ssebytemode> 2 "vector_operand" "YrBm,*xBm,xm")
           (subreg:<ssebytemode>
             (lt:VI48_AVX
               (match_operand:VI48_AVX 3 "register_operand" "Yz,Yz,x")
               (match_operand:VI48_AVX 4 "const0_operand")) 0)]
          UNSPEC_BLENDV))]

The problematic insn is:

(define_insn_and_split "*avx_cmp<mode>3_ltint_not"
 [(set (match_operand:VI48_AVX  0 "register_operand")
       (vec_merge:VI48_AVX
         (match_operand:VI48_AVX 1 "vector_operand")
         (match_operand:VI48_AVX 2 "vector_operand")
         (unspec:<avx512fmaskmode>
           [(subreg:VI48_AVX
            (not:<ssebytemode>
              (match_operand:<ssebytemode> 3 "vector_operand")) 0)
            (match_operand:VI48_AVX 4 "const0_operand")
            (match_operand:SI 5 "const_0_to_7_operand")]
            UNSPEC_PCMP)))]

which gets split to the above pattern.

In the preparation statements we have:

  if (!MEM_P (operands[3]))
    operands[3] = force_reg (<ssebytemode>mode, operands[3]);
  operands[3] = lowpart_subreg (<MODE>mode, operands[3], <ssebytemode>mode);

Which won't fly when operand 3 is memory operand...

CC author, g:8fa7216ae0d8

[Bug target/105953] [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug target/105953] [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:4b1a827f024234aaf83ecfe90415e88b525d3969

commit r13-1099-g4b1a827f024234aaf83ecfe90415e88b525d3969
Author: liuhongt <hongtao.liu@intel.com>
Date:   Tue Jun 14 16:27:04 2022 +0800

    Fix ICE in extract_insn, at recog.cc:2791

    (In reply to Uroš Bizjak from comment #1)
    > Instruction does not accept memory operand for operand 3:
    >
    > (define_insn_and_split
    > "*<sse4_1>_blendv<ssefltmodesuffix><avxsizesuffix>_ltint"
    >   [(set (match_operand:<ssebytemode> 0 "register_operand" "=Yr,*x,x")
    >       (unspec:<ssebytemode>
    >         [(match_operand:<ssebytemode> 1 "register_operand" "0,0,x")
    >          (match_operand:<ssebytemode> 2 "vector_operand" "YrBm,*xBm,xm")
    >          (subreg:<ssebytemode>
    >            (lt:VI48_AVX
    >              (match_operand:VI48_AVX 3 "register_operand" "Yz,Yz,x")
    >              (match_operand:VI48_AVX 4 "const0_operand")) 0)]
    >         UNSPEC_BLENDV))]
    >
    > The problematic insn is:
    >
    > (define_insn_and_split "*avx_cmp<mode>3_ltint_not"
    >  [(set (match_operand:VI48_AVX  0 "register_operand")
    >        (vec_merge:VI48_AVX
    >        (match_operand:VI48_AVX 1 "vector_operand")
    >        (match_operand:VI48_AVX 2 "vector_operand")
    >        (unspec:<avx512fmaskmode>
    >          [(subreg:VI48_AVX
    >           (not:<ssebytemode>
    >             (match_operand:<ssebytemode> 3 "vector_operand")) 0)
    >           (match_operand:VI48_AVX 4 "const0_operand")
    >           (match_operand:SI 5 "const_0_to_7_operand")]
    >           UNSPEC_PCMP)))]
    >
    > which gets split to the above pattern.
    >
    > In the preparation statements we have:
    >
    >   if (!MEM_P (operands[3]))
    >     operands[3] = force_reg (<ssebytemode>mode, operands[3]);
    >   operands[3] = lowpart_subreg (<MODE>mode, operands[3],
<ssebytemode>mode);
    >
    > Which won't fly when operand 3 is memory operand...
    >

    gcc/ChangeLog:

            PR target/105953
            * config/i386/sse.md (*avx_cmp<mode>3_ltint_not): Force_reg
            operands[3].

    gcc/testsuite/ChangeLog:

            * g++.target/i386/pr105953.C: New test.

[Bug target/105953] [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by hongtao Liu
<liuhongt@gcc.gnu.org>:

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

commit r12-8482-gbac09a893145056217b1e9a0054466a770815c43
Author: liuhongt <hongtao.liu@intel.com>
Date:   Tue Jun 14 16:27:04 2022 +0800

    Fix ICE in extract_insn, at recog.cc:2791

    (In reply to Uroš Bizjak from comment #1)
    > Instruction does not accept memory operand for operand 3:
    >
    > (define_insn_and_split
    > "*<sse4_1>_blendv<ssefltmodesuffix><avxsizesuffix>_ltint"
    >   [(set (match_operand:<ssebytemode> 0 "register_operand" "=Yr,*x,x")
    >       (unspec:<ssebytemode>
    >         [(match_operand:<ssebytemode> 1 "register_operand" "0,0,x")
    >          (match_operand:<ssebytemode> 2 "vector_operand" "YrBm,*xBm,xm")
    >          (subreg:<ssebytemode>
    >            (lt:VI48_AVX
    >              (match_operand:VI48_AVX 3 "register_operand" "Yz,Yz,x")
    >              (match_operand:VI48_AVX 4 "const0_operand")) 0)]
    >         UNSPEC_BLENDV))]
    >
    > The problematic insn is:
    >
    > (define_insn_and_split "*avx_cmp<mode>3_ltint_not"
    >  [(set (match_operand:VI48_AVX  0 "register_operand")
    >        (vec_merge:VI48_AVX
    >        (match_operand:VI48_AVX 1 "vector_operand")
    >        (match_operand:VI48_AVX 2 "vector_operand")
    >        (unspec:<avx512fmaskmode>
    >          [(subreg:VI48_AVX
    >           (not:<ssebytemode>
    >             (match_operand:<ssebytemode> 3 "vector_operand")) 0)
    >           (match_operand:VI48_AVX 4 "const0_operand")
    >           (match_operand:SI 5 "const_0_to_7_operand")]
    >           UNSPEC_PCMP)))]
    >
    > which gets split to the above pattern.
    >
    > In the preparation statements we have:
    >
    >   if (!MEM_P (operands[3]))
    >     operands[3] = force_reg (<ssebytemode>mode, operands[3]);
    >   operands[3] = lowpart_subreg (<MODE>mode, operands[3],
<ssebytemode>mode);
    >
    > Which won't fly when operand 3 is memory operand...
    >

    gcc/ChangeLog:

            PR target/105953
            * config/i386/sse.md (*avx_cmp<mode>3_ltint_not): Force_reg
            operands[3].

    gcc/testsuite/ChangeLog:

            * g++.target/i386/pr105953.C: New test.

[Bug target/105953] [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[crazylht at gmail dot com]

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

--- Comment #4 from Hongtao.liu <crazylht at gmail dot com> ---
Fixed in GCC12.2 and trunk.

[Bug target/105953] [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|12.3                        |12.2

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.