[Bug target/103020] New: ICE with V1TImode on x86_32

[Bug target/103020] New: ICE with V1TImode on x86_32

[ubizjak at gmail dot com]

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

            Bug ID: 103020
           Summary: ICE with V1TImode on x86_32
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
typedef int __v1ti __attribute__((mode (V1TI)));

__v1ti foo (__v1ti a)
{
  return a + a;
}
--cut here--

ICEs with gcc -O2 -msse2 -m32:

v1ti.c:1:1: warning: specifying vector types with ‘__attribute__ ((mode))’ is
deprecated [-Wattributes]
    1 | typedef int __v1ti __attribute__((mode (V1TI)));
      | ^~~~~~~
v1ti.c:1:1: note: use ‘__attribute__ ((vector_size))’ instead
during RTL pass: expand
v1ti.c: In function ‘foo’:
v1ti.c:5:12: internal compiler error: in expand_shift_1, at expmed.c:2668
    5 |   return a + a;
      |          ~~^~~
0x66ec09 expand_shift_1
        /home/uros/git/gcc/gcc/expmed.c:2668
0xa948f5 expand_shift(tree_code, machine_mode, rtx_def*, poly_int<1u, long>,
rtx_def*, int)
        /home/uros/git/gcc/gcc/expmed.c:2683
0xa948f5 expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
        /home/uros/git/gcc/gcc/expmed.c:3522
0xaada10 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /home/uros/git/gcc/gcc/expr.c:10500
...

Similar testcase:

--cut here--
typedef int __v1ti __attribute__((mode (V1TI)));

__v1ti foo (__v1ti a)
{
  return a;
}
--cut here--

does not finish compilation.

When using TI and V2TI mode, the expected error is produced:

_.c:1:1: error: unable to emulate ‘TI’

or

_.c:1:1: error: unable to emulate ‘V2TI’

[Bug target/103020] ICE with V1TImode on x86_32

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I guess that is a consequence of ix86_scalar_mode_supported_p returning false
for TImode (it uses default_scalar_mode_supported_p for it and that supports at
most 2 * BITS_PER_WORD precision modes), while ix86_vector_mode_supported_p
returns true for V1TImode (but not V2TImode etc.).
I think it has been introduced by PR32280 fix.
Seems the backend wants to use V1TImode shifts by constant for
__builtin_ia32_pslldqi128 etc.  The question is, will that keep working if we
keep V1TImode in VALID_SSE_REG_MODE etc., but add to start of
ix86_vector_mode_supported_p something like
  if (!TARGET_64BIT && GET_MODE_INNER (mode) == TImode)
    return false;

[Bug target/103020] ICE with V1TImode on x86_32

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That target hook is used mostly before expansion or during expansion:
gcc/gcc/expmed.c:           && targetm.vector_mode_supported_p (new_mode))
gcc/gcc/stor-layout.c:    && targetm.vector_mode_supported_p (trial))
gcc/gcc/targhooks.c:      && targetm.vector_mode_supported_p (result_mode))
gcc/gcc/tree.c:      && (!targetm.vector_mode_supported_p (mode)
gcc/gcc/c-family/c-attribs.c:  if (targetm.vector_mode_supported_p (mode))
gcc/gcc/d/d-target.cc:  if (!targetm.vector_mode_supported_p (TYPE_MODE
(ctype)))
so maybe using the mode in the backend only will be fine.

[Bug target/103020] ICE with V1TImode on x86_32

[jakub at gcc dot gnu.org]

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

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

Full untested patch.

[Bug target/103020] ICE with V1TImode on x86_32

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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:e178d02d390c8f972aea45c1fe5464451d818128

commit r12-4841-ge178d02d390c8f972aea45c1fe5464451d818128
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Nov 2 09:44:24 2021 +0100

    ia32: Disallow mode(V1TI) [PR103020]

    As discussed in the PR, TImode isn't supported for -m32 on x86 (for the
same
    reason as on most 32-bit targets, no support for > 2 * BITS_PER_WORD
    precision integers), but since PR32280 V1TImode is allowed with -msse in
SSE
    regs, V2TImode with -mavx or V4TImode with -mavx512f.
    typedef __int128 V __attribute__((vector_size ({16,32,64}));
    will not work, neither typedef int I __attribute__((mode(TI)));
    but mode(V1TI), mode(V2TI) etc. are accepted with a warning when those
    ISAs are enabled.  But they are certainly not fully supported, for some
    optabs maybe, but most of them will not.  And, veclower lowering those ops
    to TImode scalar operations will not work either because TImode isn't
    supported.

    So, this patch keeps V1TImode etc. in VALID*_MODE macros so that we can use
    it in certain instructions, but disallows it in
    targetm.vector_mode_supported_p, so that we don't offer those modes to the
    user as supported.

    2021-11-02  Jakub Jelinek  <jakub@redhat.com>

            PR target/103020
            * config/i386/i386.c (ix86_vector_mode_supported_p): Reject vector
            modes with TImode inner mode if 32-bit.

            * gcc.target/i386/pr103020.c: New test.

[Bug target/103020] ICE with V1TImode on x86_32

[jakub at gcc dot gnu.org]

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

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

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

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