[Bug target/106278] New: ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555

[Bug target/106278] New: ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 106278
           Summary: ICE on valid code at -Os and above on
                    x86_64-linux-gnu: in ix86_output_ssemov, at
                    config/i386/i386.cc:5555
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

[552] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220713 (experimental) [master r13-1652-g43997608a08] (GCC)
[553] %
[553] % gcctk -O1 small.c; ./a.out
[554] %
[554] % gcctk -Os small.c
during RTL pass: final
small.c: In function ‘main’:
small.c:20:1: internal compiler error: in ix86_output_ssemov, at
config/i386/i386.cc:5555
   20 | }
      | ^
0x7ba8c7 ix86_output_ssemov(rtx_insn*, rtx_def**)
        ../../gcc-trunk/gcc/config/i386/i386.cc:5555
0xb2ce53 final_scan_insn_1
        ../../gcc-trunk/gcc/final.cc:2826
0xb2d35b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
        ../../gcc-trunk/gcc/final.cc:2939
0xb2d43c final_1
        ../../gcc-trunk/gcc/final.cc:1996
0xb2e034 rest_of_handle_final
        ../../gcc-trunk/gcc/final.cc:4284
0xb2e034 execute
        ../../gcc-trunk/gcc/final.cc:4364
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[555] %
[555] % cat small.c
void __assert_fail();
struct a {
  int b;
  int c;
  int d;
  int : 2;
};
int e, f;
struct a g, i;
const struct a h;
int main() {
  struct a j;
  g = h;
  if (e)
    __assert_fail();
  if (f)
    j = h;
  i = j;
  return 0;
}

[Bug target/106278] [13 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555 since r13-1607-gc3ed9e0d6e96d869

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE on valid code at -Os    |[13 Regression] ICE on
                   |and above on                |valid code at -Os and above
                   |x86_64-linux-gnu: in        |on x86_64-linux-gnu: in
                   |ix86_output_ssemov, at      |ix86_output_ssemov, at
                   |config/i386/i386.cc:5555    |config/i386/i386.cc:5555
                   |                            |since
                   |                            |r13-1607-gc3ed9e0d6e96d869
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-07-13
            Version|unknown                     |13.0
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |sayle at gcc dot gnu.org
     Ever confirmed|0                           |1
   Target Milestone|---                         |13.0

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

[Bug target/106278] [13 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

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

--- Comment #2 from Roger Sayle <roger at nextmovesoftware dot com> ---
There's an issue updating (some) TImode REG_EQUAL notes with my recent STV
change.
I'm currently bootstraping and regression testing a fix.

[Bug target/106278] [13 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555 since r13-1607-gc3ed9e0d6e96d869

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 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:2fd215b03e88baae4e047dcb8dac5daa145dc3b4

commit r13-1707-g2fd215b03e88baae4e047dcb8dac5daa145dc3b4
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Fri Jul 15 14:39:28 2022 +0100

    PR target/106278: Keep REG_EQUAL notes consistent during TImode STV on
x86_64.

    This patch resolves PR target/106278 a regression on x86_64 caused by my
    recent TImode STV improvements.  Now that TImode STV can handle comparisons
    such as "(set (regs:CC) (compare:CC (reg:TI) ...))" the convert_insn method
    sensibly checks that the mode of the SET_DEST is TImode before setting
    it to V1TImode [to avoid V1TImode appearing on the hard reg CC_FLAGS.

    Hence the current code looks like:

          if (GET_MODE (dst) == TImode)
            {
              tmp = find_reg_equal_equiv_note (insn);
              if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
                PUT_MODE (XEXP (tmp, 0), V1TImode);
              PUT_MODE (dst, V1TImode);
              fix_debug_reg_uses (dst);
            }
          break;

    which checks GET_MODE (dst) before calling PUT_MODE, and when a
    change is made updating the REG_EQUAL_NOTE tmp if it exists.

    The logical flaw (oversight) is that due to RTL sharing, the destination
    of this set may already have been updated to V1TImode, as this chain is
    being converted, but we still need to update any REG_EQUAL_NOTE that
    still has TImode.  Hence the correct code is actually:

          if (GET_MODE (dst) == TImode)
            {
              PUT_MODE (dst, V1TImode);
              fix_debug_reg_uses (dst);
            }
          if (GET_MODE (dst) == V1TImode)
            {
              tmp = find_reg_equal_equiv_note (insn);
              if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
                PUT_MODE (XEXP (tmp, 0), V1TImode);
            }
          break;

    While fixing this behavior, I noticed I had some indentation whitespace
    issues and some vestigial dead code in this function/method that I've
    taken the liberty of cleaning up (as obvious) in this patch.

    2022-07-15  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR target/106278
            * config/i386/i386-features.cc
(general_scalar_chain::convert_insn):
            Fix indentation whitespace.
            (timode_scalar_chain::fix_debug_reg_uses): Likewise.
            (timode_scalar_chain::convert_insn): Delete dead code.
            Update TImode REG_EQUAL_NOTE even if the SET_DEST is already V1TI.
            Fix indentation whitespace.
            (convertible_comparison_p): Likewise.
            (timode_scalar_to_vector_candidate_p): Likewise.

    gcc/testsuite/ChangeLog
            * gcc.dg/pr106278.c: New test case.

[Bug target/106278] [13 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

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

--- Comment #4 from Roger Sayle <roger at nextmovesoftware dot com> ---
This shoud now be fixed.

[Bug target/106278] [13 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in ix86_output_ssemov, at config/i386/i386.cc:5555 since r13-1607-gc3ed9e0d6e96d869

[cvs-commit at gcc dot gnu.org]

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

--- 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:96e5f6696a1fa90493c464884984e9f1de86d817

commit r13-1920-g96e5f6696a1fa90493c464884984e9f1de86d817
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Mon Aug 1 23:08:23 2022 +0100

    PR target/106481: Handle CONST_WIDE_INT in REG_EQUAL during STV on x86_64.

    This patch resolves PR target/106481, and is an oversight in my recent
    battles with REG_EQUAL notes during TImode STV (see PR target/106278
    https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598416.html).

    The patch above's/current behaviour is that we check that the mode of
    the REG_EQUAL note is TImode before using PUT_MODE to set it to V1TImode.
    However, the new test case reveals that this doesn't consider REG_EQUAL
    notes that are CONST_INT or CONST_WIDE_INT, i.e. that are VOIDmode,
    and so STV produces:

    (insn 85 84 86 2 (set (reg:V1TI 113)
            (reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal}
         (expr_list:REG_EQUAL (const_wide_int 0x0ffffffff00000004)
            (nil)))

    which causes problems as the const_wide_int isn't a valid immediate
    constant for V1TImode.  With this patch, we now generate the correct:

    (insn 85 84 86 2 (set (reg:V1TI 113)
            (reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal}
         (expr_list:REG_EQUAL (const_vector:V1TI [
                    (const_wide_int 0x0ffffffff00000004)
                ])
            (nil)))

    2022-08-01  Roger Sayle  <roger@nextmovesoftware.com>
                Uroš Bizjak  <ubizjak@gmail.com>

    gcc/ChangeLog
            PR target/106481
            * config/i386/i386-features.cc (timode_scalar_chain::convert_insn):
            Convert a CONST_SCALAR_INT_P in a REG_EQUAL note into a V1TImode
            CONST_VECTOR.

    gcc/testsuite/ChangeLog
            PR target/106481
            * gcc.target/i386/pr106481.c: New test case.