[Bug target/106347] New: [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn)

[Bug target/106347] New: [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn)

[asolokha at gmx dot com]

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

            Bug ID: 106347
           Summary: [13 Regression] ICE in ix86_output_ssemov, at
                    config/i386/i386.cc:5565, or ICE in final_scan_insn_1,
                    at final.cc:2860 (error: could not split insn)
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: x86_64-unknown-linux-gnu

1.

gcc 13.0.0 20220717 snapshot (g:7bcd7f47359b903bf7a193b95d4450d9d69c60ba) ICEs
when compiling the following testcase w/ -O2 -fno-expensive-optimizations:

__int128 m;
int n;

__attribute__ ((noinline)) int
return_zero (void)
{
  return 0;
}

void
foo (void)
{
  while (m < 0)
    {
      if (n || return_zero ())
        __builtin_trap ();

      ++m;
    }
}

% x86_64-unknown-linux-gnu-gcc-13.0.0 -O2 -fno-expensive-optimizations -c
n75cwvsz.c
during RTL pass: final
n75cwvsz.c: In function 'foo':
n75cwvsz.c:20:1: internal compiler error: in ix86_output_ssemov, at
config/i386/i386.cc:5565
   20 | }
      | ^
0x7bc5e8 ix86_output_ssemov(rtx_insn*, rtx_def**)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/config/i386/i386.cc:5565
0xb34761 final_scan_insn_1
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:2826
0xb34d0b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:2939
0xb34eb4 final_1
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:1996
0xb35a66 rest_of_handle_final
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:4284
0xb35a66 execute
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:4364

2.

Changing "while (m < 0)" to "while (m < 1)" yields the following ICE instead:

n75cwvsz.c:20:1: error: could not split insn
   20 | }
      | ^
(insn:TI 3 57 93 5 (set (mem/c:V1TI (reg/f:DI 7 sp) [3 %sfp+-16 S16 A128])
        (reg:TI 4 si [orig:84 _3 ] [84])) "n75cwvsz.c":18:7 81
{*movti_internal}
     (nil))
during RTL pass: final
n75cwvsz.c:20:1: internal compiler error: in final_scan_insn_1, at
final.cc:2860
0x727cc3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/rtl-error.cc:108
0x6bc2f0 final_scan_insn_1
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:2860
0xb34d0b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:2939
0xb34eb4 final_1
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:1996
0xb35a66 rest_of_handle_final
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:4284
0xb35a66 execute
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220717/work/gcc-13-20220717/gcc/final.cc:4364

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn)

[crazylht at gmail dot com]

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

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #1 from Hongtao.liu <crazylht at gmail dot com> ---
It looks like a dup of PR106278

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn)

[crazylht at gmail dot com]

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

--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #1)
> It looks like a dup of PR106278

and It seems PR106278 is not fully fixed.

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
            Summary|[13 Regression] ICE in      |[13 Regression] ICE in
                   |ix86_output_ssemov, at      |ix86_output_ssemov, at
                   |config/i386/i386.cc:5565,   |config/i386/i386.cc:5565,
                   |or ICE in                   |or ICE in
                   |final_scan_insn_1, at       |final_scan_insn_1, at
                   |final.cc:2860 (error: could |final.cc:2860 (error: could
                   |not split insn)             |not split insn) since
                   |                            |r13-1607-gc3ed9e0d6e96d869
   Last reconfirmed|                            |2022-07-19
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r13-1607-gc3ed9e0d6e96d869.

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

--- Comment #4 from Roger Sayle <roger at nextmovesoftware dot com> ---
No, it's not PR 106278 that this PR is similar to (which concerned REG_EQUAL
notes and is now fixed), but PR 106303 (which concerns STV converting some
mentions of a TImode register/memory, and not others, due to data flow analysis
and rtx sharing) which is still open/unresolved.

My apologies for the inconvenience, figuring out why the pre-existing STV
infrastructure is making some of these counter-intuitive decisions, and what
the intended behavior should be, is taking some time.  Obviously -mno-stv is a
work around.

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

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

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:76d6224b944e1a66bfb1195fb7d35d9726f1aed8

commit r13-1811-g76d6224b944e1a66bfb1195fb7d35d9726f1aed8
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Sun Jul 24 12:22:22 2022 +0100

    PR target/106303: Fix TImode STV related failures on x86.

    This patch resolves PR target/106303 (and the related PRs 106347,
    106404, 106407) which are ICEs caused by my improvements to x86_64's
    128-bit TImode to V1TImode Scalar to Vector (STV) pass.  My apologies
    for the breakage.  The issue is that data flow analysis is used to
    partition usage of each TImode pseudo into "chains", where each
    chain is analyzed and if suitable converted to vector operations.
    The problems appears when some chains for a pseudo are converted,
    and others aren't as RTL sharing can result in some mode changes
    leaking into other instructions that aren't/shouldn't/can't be
    converted, which eventually leads to an ICE for mismatched modes.

    My first approach to a fix was to unify more of the STV infrastructure,
    reasoning that if TImode STV was exhibiting these problems, but DImode
    and SImode STV weren't, the issue was likely to be caused/resolved by
    these remaining differences.  This appeared to fix some but not all of
    the reported PRs.  A better solution was then proposed by H.J. Lu in
    Bugzilla, that we need to iterate the removal of candidates in the
    function timode_remove_non_convertible_regs until there are no further
    changes.  As each chain is removed from consideration, it in turn may
    affect whether other insns/chains can safely be converted.

    2022-07-24  Roger Sayle  <roger@nextmovesoftware.com>
                H.J. Lu  <hjl.tools@gmail.com>

    gcc/ChangeLog
            PR target/106303
            PR target/106347
            * config/i386/i386-features.cc (make_vector_copies): Move from
            general_scalar_chain to scalar_chain.
            (convert_reg): Likewise.
            (convert_insn_common): New scalar_chain method split out from
            general_scalar_chain convert_insn.
            (convert_registers): Move from general_scalar_chain to
            scalar_chain.
            (scalar_chain::convert): Call convert_insn_common before calling
            convert_insn.
            (timode_remove_non_convertible_regs): Iterate until there are
            no further changes to the candidates.
            * config/i386/i386-features.h (scalar_chain::hash_map): Move
            from general_scalar_chain.
            (scalar_chain::convert_reg): Likewise.
            (scalar_chain::convert_insn_common): New shared method.
            (scalar_chain::make_vector_copies): Move from general_scalar_chain.
            (scalar_chain::convert_registers): Likewise.  No longer virtual.
            (general_scalar_chain::hash_map): Delete.  Moved to scalar_chain.
            (general_scalar_chain::convert_reg): Likewise.
            (general_scalar_chain::make_vector_copies): Likewise.
            (general_scalar_chain::convert_registers): Delete virtual method.
            (timode_scalar_chain::convert_registers): Likewise.

    gcc/testsuite/ChangeLog
            PR target/106303
            PR target/106347
            * gcc.target/i386/pr106303.c: New test case.
            * gcc.target/i386/pr106347.c: New test case.

[Bug target/106347] [13 Regression] ICE in ix86_output_ssemov, at config/i386/i386.cc:5565, or ICE in final_scan_insn_1, at final.cc:2860 (error: could not split insn) since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

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

--- Comment #6 from Roger Sayle <roger at nextmovesoftware dot com> ---
This should now be fixed on mainline.