[Bug c++/95528] New: internal compiler error: in emit_move_insn, at expr.c:3814

[Bug c++/95528] New: internal compiler error: in emit_move_insn, at expr.c:3814

[slyfox at inbox dot ru]

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

            Bug ID: 95528
           Summary: internal compiler error: in emit_move_insn, at
                    expr.c:3814
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at inbox dot ru
  Target Milestone: ---

The bug is initially reported in https://bugs.gentoo.org/727028 as an ICE on
firefox-77 code by Thomas Deutschmann.

Here is the minimal reproducer reduced by creduce:

$ cat bug.cc
template <typename a> struct b {
  typedef a c __attribute__((vector_size(sizeof(a) * 4)));
  union {
    c d;
    struct {
      a e, f, g, h;
    };
  };
  b();
  b(const b &i) : d(i.d) {}
  static b j(c);
  template <typename k> operator b<k>() {
    b<k>::j(typename b<k>::c{e, f, g, h});
  }
};
template <typename a> using l = b<a>;
using m = l<char>;
using n = l<short>;
m o(n i) { return i; }
b<short> q;
void p() { o(q); }

$ LANG=C /usr/bin/x86_64-pc-linux-gnu-g++ -march=skylake-avx512 -O2 -c bug.cc
-o bug.o

during RTL pass: expand
bug.cc: In function 'void p()':
bug.cc:13:12: internal compiler error: in emit_move_insn, at expr.c:3814
   13 |     b<k>::j(typename b<k>::c{e, f, g, h});
      |     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x5cb5cc emit_move_insn(rtx_def*, rtx_def*)
        ../../gcc-11.0.0_pre9999/gcc/expr.c:3814
0x82e459 load_register_parameters
        ../../gcc-11.0.0_pre9999/gcc/calls.c:3143
0x82e459 expand_call(tree_node*, rtx_def*, int)
        ../../gcc-11.0.0_pre9999/gcc/calls.c:4589
0x942856 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        ../../gcc-11.0.0_pre9999/gcc/expr.c:11135
0x94cc64 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
        ../../gcc-11.0.0_pre9999/gcc/expr.c:8358
0x94cc64 store_expr(tree_node*, rtx_def*, int, bool, bool)
        ../../gcc-11.0.0_pre9999/gcc/expr.c:5752
0x94e1f9 expand_assignment(tree_node*, tree_node*, bool)
        ../../gcc-11.0.0_pre9999/gcc/expr.c:5514
0x83c40a expand_call_stmt
        ../../gcc-11.0.0_pre9999/gcc/cfgexpand.c:2701
0x83c40a expand_gimple_stmt_1
        ../../gcc-11.0.0_pre9999/gcc/cfgexpand.c:3682
0x83c40a expand_gimple_stmt
        ../../gcc-11.0.0_pre9999/gcc/cfgexpand.c:3847
0x842916 expand_gimple_basic_block
        ../../gcc-11.0.0_pre9999/gcc/cfgexpand.c:5887
0x842916 execute
        ../../gcc-11.0.0_pre9999/gcc/cfgexpand.c:6571
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.

Both gcc-10 and gcc-master are affected.

gcc-master crash for comparison:

$ ${HOME}/dev/git/gcc-native-quick/gcc/xg++ -B
${HOME}/dev/git/gcc-native-quick/gcc -march=skylake-avx512 -O2 -c bug.cc -o
bug.o

during RTL pass: expand
bug.cc: In function 'void p()':
bug.cc:13:12: internal compiler error: in emit_move_insn, at expr.c:3814
   13 |     b<k>::j(typename b<k>::c{e, f, g, h});
      |     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x7f1550e53d59 __libc_start_main
        ../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ ${HOME}/dev/git/gcc-native-quick/gcc/xg++ -B
${HOME}/dev/git/gcc-native-quick/gcc -v
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xg++
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --disable-bootstrap
--with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls --without-isl --disable-libsanitizer --disable-libvtv
--disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions
CFLAGS='-O1 ' CXXFLAGS='-O1 ' --with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200604 (experimental) (GCC)

Not sure if it's the same as bug #95394. That bug says it's a gcc-11
regression, but this one happens on gcc-10.1.0 as well.

[Bug c++/95528] internal compiler error: in emit_move_insn, at expr.c:3814

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich <slyfox at inbox dot ru> ---
It seems to be somehow specific to avx512:

This works:
$ LANG=C /usr/bin/x86_64-pc-linux-gnu-g++-10.1.0 -march=skylake -O2 -c bug.cc
-o bug.o

This ICEs:
$ LANG=C /usr/bin/x86_64-pc-linux-gnu-g++-10.1.0 -march=skylake-avx512 -O2 -c
bug.cc -o bug.o

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |middle-end
            Summary|internal compiler error: in |[10/11 Regression] internal
                   |emit_move_insn, at          |compiler error: in
                   |expr.c:3814                 |emit_move_insn, at
                   |                            |expr.c:3814
           Keywords|                            |ice-on-valid-code,
                   |                            |needs-bisection
   Target Milestone|---                         |10.2
             Target|                            |x86_64-*-* i?86-*-*

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[ubizjak at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-06-04
     Ever confirmed|0                           |1

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Something is wrong with the handling of:

(define_expand "vec_pack_trunc_<mode>"
  [(set (match_operand:<DOUBLEMASKMODE> 0 "register_operand")
        (ior:<DOUBLEMASKMODE>
          (ashift:<DOUBLEMASKMODE>
            (zero_extend:<DOUBLEMASKMODE>
              (match_operand:SWI24 2 "register_operand"))
            (match_dup 3))
          (zero_extend:<DOUBLEMASKMODE>
            (match_operand:SWI24 1 "register_operand"))))]
  "TARGET_AVX512BW"
{
  operands[3] = GEN_INT (GET_MODE_BITSIZE (<MODE>mode));
})

Disabling this expander "fixes" the testcase.

"-O2 -mavx512bw" is needed.

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
Introduced by[1].

[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bea408857a7d

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Adjusted testcase so that there are no warnings:
template <typename a> struct b {
  typedef a c __attribute__((vector_size(sizeof(a) * 4)));
  union {
    c d;
    struct {
      a e, f, g, h;
    };
  };
  b();
  b(const b &i) : d(i.d) {}
  static b j(c);
  template <typename k> operator b<k>() {
    b<k>::j(typename b<k>::c{k(e), k(f), k(g), k(h)});
    return b<k>();
  }
};
template <typename a> using l = b<a>;
using m = l<char>;
using n = l<short>;
m o(n i) { return i; }
b<short> q;
void p() { o(q); }

What vec_pack_trunc_si does looks completely reasonable for the vector bool
types that have integral modes (i.e. AVX512F+ masks).
I'd say the vectorizer/simplify_vector_constructor just shouldn't attempt to
use these (e.g. vec_pack*, vec_unpack* optabs) for !VEC_MODE_P unless it is
VECTOR_BOOLEAN_TYPE_P type.
For i386 it would be the right thing as the patterns really assume that it is
vector booleans and have their properties.
Though, aarch64 seems to have vec_pack_trunc_di and vec_pack_trunc_df
expanders, it is unclear to me what they are for and if they are really used.
Other targets seem to only define these for vector modes.

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[slyfox at inbox dot ru]

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

--- Comment #5 from Sergei Trofimovich <slyfox at inbox dot ru> ---
My bisect ended up at:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=78307657cf9675bc4aa2e77561c823834714b4c8

$ git bisect bad
78307657cf9675bc4aa2e77561c823834714b4c8 is the first bad commit
commit 78307657cf9675bc4aa2e77561c823834714b4c8
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Nov 28 12:22:04 2019 +0000

    re PR tree-optimization/92645 (Hand written vector code is 450 times slower
when compiled with GCC compared to Clang)

    2019-11-28  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/92645
            * tree-ssa-forwprop.c (get_bit_field_ref_def): Also handle
            conversions inside a mode class.  Remove restriction on
            preserving the element size.
            (simplify_vector_constructor): Deal with the above and for
            identity permutes also try using VEC_UNPACK_[FLOAT_]LO_EXPR
            and VEC_PACK_TRUNC_EXPR.

            * gcc.target/i386/pr92645-4.c: New testcase.

    From-SVN: r278806

 gcc/ChangeLog                             | 10 ++++
 gcc/testsuite/ChangeLog                   |  5 ++
 gcc/testsuite/gcc.target/i386/pr92645-4.c | 56 ++++++++++++++++++
 gcc/tree-ssa-forwprop.c                   | 96 ++++++++++++++++++++++++++-----
 4 files changed, 154 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr92645-4.c

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> I'd say the vectorizer/simplify_vector_constructor just shouldn't attempt to
> use these (e.g. vec_pack*, vec_unpack* optabs) for !VEC_MODE_P unless it is
> VECTOR_BOOLEAN_TYPE_P type.
> For i386 it would be the right thing as the patterns really assume that it
> is vector booleans and have their properties.
> Though, aarch64 seems to have vec_pack_trunc_di and vec_pack_trunc_df
> expanders, it is unclear to me what they are for and if they are really used.
> Other targets seem to only define these for vector modes.
Yeah, I agree those look odd.  The covering note for the patch
that added them was:

  https://gcc.gnu.org/pipermail/gcc-patches/2013-April/361636.html

which talks about fixing gcc.dg/vect failures.  But as James says,
only the 128-bit patterns should be needed for that.  Maybe the
the 64-bit patterns were just added for completeness.

Perhaps one justification for _di is that there is no V1DI mode.
Instead a vector of 1 DImode would itself have mode DImode.
So in principle, vec_pack_trunc_di is probably the right name
for a (V1)DI->V2SI truncate.

The same doesn't apply to _df since we don't use scalar float
modes for V1 vectors.  And (unlike at the time of the patch)
we now have V1DF.  So I agree that the _df one looks dead.

That said, for AArch64 we'd now try to mix 128-bit and 64-bit
vectors instead of vectorising with 2 64-bit vectors.  So the
_di pattern probably isn't useful in practice either.

In summary: from an AArch64 perspective, it's probably fine to
check !VECTOR_MODE_P || VECTOR_BOOLEAN_TYPE_P.  But given the V1
thing, maybe it would be better to add || m == GET_MODE_INNER (m)
as well (unless that defeats the fix).

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to rsandifo@gcc.gnu.org from comment #6)
> In summary: from an AArch64 perspective, it's probably fine to
> check !VECTOR_MODE_P || VECTOR_BOOLEAN_TYPE_P.  But given the V1
> thing, maybe it would be better to add || m == GET_MODE_INNER (m)
> as well (unless that defeats the fix).
Er, I mean: m == TYPE_MODE (TREE_TYPE (vectype)) or whatever.
m == GET_MODE_INNER (m) is of course always true for scalars :-)

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48683&action=edit
gcc11-pr95528.patch

Untested fix.

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 48683 [details]
> gcc11-pr95528.patch
> 
> Untested fix.
The VECTOR_TYPE_P condition should be redundant.
Looks good to me otherwise FWIW.

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 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:8be374e02761c9d63d2753d71e4bd4874a1577b1

commit r11-1065-g8be374e02761c9d63d2753d71e4bd4874a1577b1
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Jun 8 11:05:10 2020 +0200

    forwprop: Ignore scalar mode vectors in simplify_vector_constructor
[PR95528]

    As mentioned in the PR, the problem is that at least the x86 backend asumes
    that the vec_unpack* and vec_pack* optabs with integral modes are for the
    AVX512-ish vector masks rather than for very small vectors done in GPRs.
    The only other target that seems to have a scalar mode vec_{,un}pack* optab
    is aarch64 as discussed in the PR, so there is also a condition for that.
    All other targets have just vector mode optabs.

    2020-06-08  Jakub Jelinek  <jakub@redhat.com>

            PR target/95528
            * tree-ssa-forwprop.c (simplify_vector_constructor): Don't use
            VEC_UNPACK*_EXPR or VEC_PACK_TRUNC_EXPR with scalar modes unless
the
            type is vector boolean.

            * g++.dg/opt/pr95528.C: New test.

[Bug middle-end/95528] [10 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11 Regression] internal |[10 Regression] internal
                   |compiler error: in          |compiler error: in
                   |emit_move_insn, at          |emit_move_insn, at
                   |expr.c:3814                 |expr.c:3814

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug middle-end/95528] [10 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r10-8296-gc75a2abc3a976096b89475f062d4795247aa02b8
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Jun 8 11:05:10 2020 +0200

    forwprop: Ignore scalar mode vectors in simplify_vector_constructor
[PR95528]

    As mentioned in the PR, the problem is that at least the x86 backend asumes
    that the vec_unpack* and vec_pack* optabs with integral modes are for the
    AVX512-ish vector masks rather than for very small vectors done in GPRs.
    The only other target that seems to have a scalar mode vec_{,un}pack* optab
    is aarch64 as discussed in the PR, so there is also a condition for that.
    All other targets have just vector mode optabs.

    2020-06-08  Jakub Jelinek  <jakub@redhat.com>

            PR target/95528
            * tree-ssa-forwprop.c (simplify_vector_constructor): Don't use
            VEC_UNPACK*_EXPR or VEC_PACK_TRUNC_EXPR with scalar modes unless
the
            type is vector boolean.

            * g++.dg/opt/pr95528.C: New test.

    (cherry picked from commit 8be374e02761c9d63d2753d71e4bd4874a1577b1)

[Bug middle-end/95528] [10 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.2+ too.