[Bug c/109302] New: [12/13 Regression] ICE in emit_move_insn, at expr.cc:4225

[Bug c/109302] New: [12/13 Regression] ICE in emit_move_insn, at expr.cc:4225

[gscfq@t-online.de]

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

            Bug ID: 109302
           Summary: [12/13 Regression] ICE in emit_move_insn, at
                    expr.cc:4225
           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 20210905 and 20210919, with -mavx512f or -mavx512pf :


$ cat z1.c
typedef unsigned U __attribute__ ((vector_size (64)));
typedef unsigned __int128 V __attribute__ ((vector_size (64)));
static inline V
bar (U u, U x, V v)
{
  v = (V)(U) { 0, ~0 };
  v[x[0]] <<= u[-63];
  return v;
}
__attribute__((target_clones("arch=x86-64", "default")))
V
foo (U u)
{
  return bar (u, (U) {}, (V) {});
}


$ gcc-13-20230326 -c z1.c -O2 -mavx512f
In function 'foo.arch_x86_64':
cc1: warning: AVX512F vector return without AVX512F enabled changes the ABI
[-Wpsabi]
z1.c:12:1: note: the ABI for passing parameters with 64-byte alignment has
changed in GCC 4.6
   12 | foo (U u)
      | ^~~
z1.c:12:1: warning: AVX512F vector argument without AVX512F enabled changes the
ABI [-Wpsabi]
during RTL pass: expand
z1.c:14:10: internal compiler error: in emit_move_insn, at expr.cc:4225
   14 |   return bar (u, (U) {}, (V) {});
      |          ^~~~~~~~~~~~~~~~~~~~~~~
0x91273d emit_move_insn(rtx_def*, rtx_def*)
        ../../gcc/expr.cc:4224
0x9203d0 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        ../../gcc/expr.cc:10580
0x910a95 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        ../../gcc/expr.cc:10801
0x9198b3 store_expr(tree_node*, rtx_def*, int, bool, bool)
        ../../gcc/expr.cc:6330
0x91af3e expand_assignment(tree_node*, tree_node*, bool)
        ../../gcc/expr.cc:6048
0x80afa0 expand_gimple_stmt_1
        ../../gcc/cfgexpand.cc:3946
0x80afa0 expand_gimple_stmt
        ../../gcc/cfgexpand.cc:4044
0x8101a7 expand_gimple_basic_block
        ../../gcc/cfgexpand.cc:6106
0x812c6e execute
        ../../gcc/cfgexpand.cc:6841

[Bug target/109302] [12/13 Regression] ICE in emit_move_insn, at expr.cc:4225

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-03-28
     Ever confirmed|0                           |1
   Target Milestone|---                         |12.3
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |needs-bisection
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug target/109302] [12/13 Regression] ICE in emit_move_insn, at expr.cc:4225

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This used to ICE in various spots long time ago, then was for some years
rejected with
error: No dispatcher found for the versioning attributes
which changed with r12-3494-g8ea292591e42aa4d52b.  Since that it ICEs in the
current spot.

[Bug target/109302] [12/13 Regression] ICE in emit_move_insn, at expr.cc:4225

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the problem is that ccp1 decides to fold
  _4 = 0;
...
  VIEW_CONVERT_EXPR<__int128 unsigned[4]>(v)[_4] = _8;
into
  v_18 = BIT_INSERT_EXPR <v_13, _8, 0 (128 bits)>;
while the function is still TARGET_AVX512F and so has V4TImode support.
Later on during IPA the function is multi-versioned and one version has smaller
ISA support than before, nothing (e.g. generic vector lowering) lowers that
BIT_INSERT_EXPR
and expansion can't handle BLKmode BIT_INSERT_EXPR either.

Now, do we want to really support this loophole for lowering ISA capabilities?

I mean, say
#include <x86intrin.h>

__attribute__((target_clones("arch=x86-64", "default"))) __m512i
foo (__m512i a, __m512i b, __m512i c, __mmask8 d)
{
  return _mm512_mask_ternarylogic_epi64 (a, d, b, c, 3);
}
when compiled with -O2 -mno-sse3 it is rejected with
error: inlining failed in call to ‘always_inline’
‘_mm512_mask_ternarylogic_epi64’: target specific option mismatch
while with -O2 -mavx512f in this case it is caught during expansion:
error: ‘__builtin_ia32_pternlogq512_mask’ needs isa option -mavx512f
(which is still needed if one would use the builtins by hand), but generally,
we could
e.g. gimple_fold etc. something that we couldn't handle properly later on.

If we want to support this mess, should we handle it in generic vector lowering
or expansion?

[Bug target/109302] [12/13/14 Regression] ICE in emit_move_insn, at expr.cc:4225

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.3                        |12.4

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.

[Bug target/109302] [12/13/14 Regression] ICE in emit_move_insn, at expr.cc:4225

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |accepts-invalid

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think target_clones shouldn't support any ISA that doesn't have the global
enabled ISAs enabled - that's just asking for troubles, because the
dispatcher is built then with a higher ISA enabled than the dispatched-to
function for example.

So I think we should reject this.

[Bug target/109302] [12/13/14 Regression] ICE in emit_move_insn, at expr.cc:4225

[rguenth at gcc dot gnu.org]

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

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

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