[Bug tree-optimization/99746] New: ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[Bug tree-optimization/99746] New: ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[asolokha at gmx dot com]

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

            Bug ID: 99746
           Summary: ICE in vect_get_vec_defs_for_operand, at
                    tree-vect-stmts.c:1450
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: aarch64-linux-gnu

Created attachment 50467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50467&action=edit
Testcase

gfortran-11.0.1-alpha20210321 snapshot
(g:fc24ea2374259d401a46ce3526688b7e79d4cc13) ICEs when compiling the attached
testcase w/ -march=armv8.3-a -O2 -ftree-loop-vectorize:

% aarch64-linux-gnu-gfortran-11.0.1 -march=armv8.3-a -O2 -ftree-loop-vectorize
-c k8x66s8b.f
during GIMPLE pass: vect
k8x66s8b.f:1:23:

    1 |       SUBROUTINE CLAREF(A, LDA, WANTZ, Z, BLOCK, IROW1, ICOL1,
      |                       ^
internal compiler error: in vect_get_vec_defs_for_operand, at
tree-vect-stmts.c:1450
0x7ba760 vect_get_vec_defs_for_operand(vec_info*, _stmt_vec_info*, unsigned
int, tree_node*, vec<tree_node*, va_heap, vl_ptr>*, tree_node*)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/tree-vect-stmts.c:1450
0x11e6df6 vectorizable_call
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/tree-vect-stmts.c:3459
0x11f6478 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/tree-vect-stmts.c:10962
0x11f9ce5 vect_transform_loop_stmt
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/tree-vect-loop.c:9212
0x1215d5c vect_transform_loop(_loop_vec_info*, gimple*)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/tree-vect-loop.c:9641
0x1244daf try_vectorize_loop_1
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/tree-vectorizer.c:1104
0x1245b50 vectorize_loops()
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/tree-vectorizer.c:1243

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

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

--- Comment #1 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
That testcase doesn't seem to compile.  It looks like some line numbering etc
snuck in.  Tried to repair it but don't know enough fortran to.

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-03-24
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #1)
> That testcase doesn't seem to compile.  It looks like some line numbering
> etc snuck in.  Tried to repair it but don't know enough fortran to.

I can reproduce it. You likely named the file x.f90 (and not x.f). Please try
that..

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Do you want me to bisect that?

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
> I can reproduce it. You likely named the file x.f90 (and not x.f). Please try that..

Aha.. Fortran such a mystery :)

> Do you want me to bisect that?

No, they'll all point to the commit which introduced the optabs, since that's
the one causing the vectorizer to go down this path.  But it won't be the
actual commit with the changes to the vectorizer.

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #4)
> > I can reproduce it. You likely named the file x.f90 (and not x.f). Please try that..
> 
> Aha.. Fortran such a mystery :)

Yep, all black magic. Btw. one can convert the forms with:
https://github.com/ylikx/fortran-legacy-tools/blob/master/fixed2free/fixed2free2.py

> 
> > Do you want me to bisect that?
> 
> No, they'll all point to the commit which introduced the optabs, since
> that's the one causing the vectorizer to go down this path.  But it won't be
> the actual commit with the changes to the vectorizer.

Good, have fun.

[Bug tree-optimization/99746] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
A bit reduced test-case:

SUBROUTINE CLAREF(A, WANTZ, Z, ICOL1, ITMP1, ITMP2, T1, T2, V2)
LOGICAL            BLOCK, WANTZ
COMPLEX            T1, T2, V2
COMPLEX            A(LDA, *), VECS, Z(LDA, *)
COMPLEX            SUM 
LOGICAL            LSAME
IF (LSAME) THEN
      DO 30 K = ITMP1, ITMP2, 3
         T1 = VECS0
30       CONTINUE
ELSE
   IF (BLOCK) THEN
      DO 90 K = ITMP1, ITMP2 - 1, 3
         A(J, ICOL1) = ITMP1
         IF (WANTZ) THEN
            DO 80 J = ITMP1, ITMP2
               SUM =  ICOL1
               Z(J, 3) = V23
80             CONTINUE
         END IF
90       CONTINUE
      DO 120 K = ITMP1, ITMP2
         V2 = VECS()
         DO 100 J = ITMP1, ITMP2
            A(J, ICOL1) = A(J, ICOL1) - SUM
100          CONTINUE
         IF (WANTZ) THEN
            DO 110 J = 1, 3
               SUM = Z(J, ICOL1)
               Z(J, ICOL1) = 0
110             CONTINUE
         END IF
         ICOL1 = ICOL1 + 1
120       CONTINUE
   ELSE
      DO 130 J = ITMP1, ITMP2
         SUM = T1 * A(J, ICOL1) + T2 * A(J, 1) + V2 * A(J, 2)
         A(J, ICOL1) = SUM
         A(J, ICOL1 + 2) = SUM * V1
130       CONTINUE
   END IF
END IF
END

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |11.0
            Summary|ICE in                      |[11 Regression] ICE in
                   |vect_get_vec_defs_for_opera |vect_get_vec_defs_for_opera
                   |nd, at                      |nd, at
                   |tree-vect-stmts.c:1450      |tree-vect-stmts.c:1450

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #7 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
reduced to

      SUBROUTINE CLAREF(A)
      LOGICAL            BLOCK
      COMPLEX            T1 , V2
      COMPLEX            A(LDA, *) , SUM
      LOGICAL            LSAME
      IF (LSAME) THEN
         IF (BLOCK) THEN
            DO 130 J = ITMP1, ITMP2
               SUM = T1 * A(J, ICOL1) * A0 +
     $               V2 * A(J, 2)
               A(J, ICOL1) = -SUM
               A(J, 2) = SUM
  130       CONTINUE
         END IF
      END IF
      END

which produces the following SLP tree,

   node 0x4e150c0 (max_nunits=2, refcnt=1)
   op template: REALPART_EXPR <(*a_29(D))[_12]> = sum$real_60;
         stmt 0 REALPART_EXPR <(*a_29(D))[_12]> = sum$real_60;
         stmt 1 IMAGPART_EXPR <(*a_29(D))[_12]> = sum$imag_61;
         children 0x4e15720
   node 0x4e15720 (max_nunits=2, refcnt=1)
   op template: slp_patt_69 = .COMPLEX_FMA (sum$real_60, sum$real_60,
sum$real_60);
         stmt 0 sum$real_60 = _48 + _58;
         stmt 1 sum$imag_61 = _49 + _59;
         children 0x4e15500 0x4e15e08 0x4e15ad8
   node 0x4e15500 (max_nunits=2, refcnt=1)
   op template: _48 = a0_31(D) * _46;
         stmt 0 _48 = a0_31(D) * _46;
         stmt 1 _49 = a0_31(D) * _47;
         children 0x4e15588 0x4e151d0
   node (external) 0x4e15588 (max_nunits=1, refcnt=1)
         { a0_31(D), a0_31(D) }
   node 0x4e151d0 (max_nunits=2, refcnt=1)
   op template: slp_patt_71 = .COMPLEX_MUL (_46, _46);
         stmt 0 _46 = _42 - _43;
         stmt 1 _47 = _44 + _45;
         children 0x4e15038 0x4e15d80
   node (external) 0x4e15038 (max_nunits=1, refcnt=1)
         { t1$real_38(D), t1$imag_41(D) }
   node 0x4e15d80 (max_nunits=2, refcnt=2)
   op template: _17 = REALPART_EXPR <(*a_29(D))[_5]>;
         stmt 0 _17 = REALPART_EXPR <(*a_29(D))[_5]>;
         stmt 1 _16 = IMAGPART_EXPR <(*a_29(D))[_5]>;
         load permutation { 0 1 }
   node 0x4e15e08 (max_nunits=2, refcnt=2)
   op template: _50 = REALPART_EXPR <(*a_29(D))[_12]>;
         stmt 0 _50 = REALPART_EXPR <(*a_29(D))[_12]>;
         stmt 1 _51 = IMAGPART_EXPR <(*a_29(D))[_12]>;
         load permutation { 0 1 }
   node (external) 0x4e15ad8 (max_nunits=1, refcnt=1)
         { v2$real_52(D), v2$imag_53(D) }

which is correct, but vect_detect_hybrid_slp determines

   marking hybrid: slp_patt_71 = .COMPLEX_MUL (_46, _46);

Which is a problem since the patterns are only valid in SLP.

I don't quite see why the sub-tree is hybrid though.. it determines

   marking hybrid: _50 = REALPART_EXPR <(*a_29(D))[_12]>;
   marking hybrid: _51 = IMAGPART_EXPR <(*a_29(D))[_12]>;
   marking hybrid: _48 = a0_31(D) * _46;
   marking hybrid: slp_patt_71 = .COMPLEX_MUL (_46, _46);
   marking hybrid: sum$imag_61 = _49 + _59;
   marking hybrid: _49 = a0_31(D) * _47;
   marking hybrid: _59 = _56 + _57;
   marking hybrid: _56 = _50 * v2$imag_53(D);
   marking hybrid: _57 = _51 * v2$real_52(D);
   marking hybrid: _47 = _44 + _45;
   marking hybrid: _44 = _17 * t1$imag_41(D);
   marking hybrid: _45 = _16 * t1$real_38(D);
   marking hybrid: _16 = IMAGPART_EXPR <(*a_29(D))[_5]>;
   marking hybrid: _17 = REALPART_EXPR <(*a_29(D))[_5]>;

So either the vect_detect_hybrid_slp is correct but then SLP should be aborted
or it's not right and this should have been pure.

the problem starts because it marks _50 as hybrid, but don't see why it thinks
that...

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm testing the following:

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index f1a2b5d60fa..762cba54bb5 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3770,6 +3770,20 @@ vect_slp_analyze_node_operations_1 (vec_info *vinfo,
slp_tree node,
       return false;
     }

+  /* ???  We're getting confused with pattern marking since the loop
+     vect part would need to use the original scalar stmts but we've
+     registered the SLP pattern as pattern stmt for those which isn't
+     technically correct.  Give up for now.  */
+  if (STMT_VINFO_SLP_VECT_ONLY_PATTERN (stmt_info)
+      && HYBRID_SLP_STMT (stmt_info))
+    {
+      if (dump_enabled_p ())
+       dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+                        "cannot do hybrid SLP on SLP pattern "
+                        "stmt %G", stmt_info->stmt);
+      return false;
+    }
+
   bool dummy;
   return vect_analyze_stmt (vinfo, stmt_info, &dummy,
                            node, node_instance, cost_vec);

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[tnfchris at gcc dot gnu.org]

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

--- Comment #9 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
@Arseny,

Thanks for reporting these.

I wonder if whatever you're compiling is open source.  I'd love to fix some of
these cases properly in GCC 12.

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[asolokha at gmx dot com]

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

--- Comment #10 from Arseny Solokha <asolokha at gmx dot com> ---
(In reply to Tamar Christina from comment #9)
> I wonder if whatever you're compiling is open source.  I'd love to fix some
> of these cases properly in GCC 12.

These Fortran snippets I've been filing this week are from SCALAPACK 2.0.2 as
found on Netlib[1].

[1] https://www.netlib.org/scalapack

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #7)
> the problem starts because it marks _50 as hybrid, but don't see why it
> thinks that...

Because

t.f:36:16: note:   Processing hybrid candidate : IMAGPART_EXPR
<(*a_117(D))[_73]> = _189;
t.f:36:16: note:   Found loop_vect sink: IMAGPART_EXPR <(*a_117(D))[_73]> =
_189;
t.f:36:16: note:   Processing hybrid candidate : REALPART_EXPR
<(*a_117(D))[_73]> = _188;
t.f:36:16: note:   Found loop_vect sink: REALPART_EXPR <(*a_117(D))[_73]> =
_188;

so there are not SLPed stores which makes the whole use-def chain of
_189 and _188 loop vectorized (and hybrid if it has common pieces using SLP
vectorization).

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, the following also works as a fix but obviously I'm not in a position to
fully evaluate this.  That said, hybrid SLP detection was rewritten during
SLP pattern development so the requirement to hook things up as regular
pattern might no longer be there.

Tamar - can you fully test this on aarch64?  I see the testcase from this
PR being hybrid vectorized appropriately then.

diff --git a/gcc/tree-vect-slp-patterns.c b/gcc/tree-vect-slp-patterns.c
index 85f2d03754d..cdd61e9a5cf 100644
--- a/gcc/tree-vect-slp-patterns.c
+++ b/gcc/tree-vect-slp-patterns.c
@@ -571,14 +571,8 @@ complex_pattern::build (vec_info *vinfo)
       STMT_VINFO_RELEVANT (call_stmt_info) = vect_used_in_scope;
       STMT_SLP_TYPE (call_stmt_info) = pure_slp;

-      /* add_pattern_stmt can't be done in vect_mark_pattern_stmts because
-        the non-SLP pattern matchers already have added the statement to VINFO
-        by the time it is called.  Some of them need to modify the returned
-        stmt_info.  vect_mark_pattern_stmts is called by recog_pattern and it
-        would increase the size of each pattern with boilerplate code to make
-        the call there.  */
-      vect_mark_pattern_stmts (vinfo, stmt_info, call_stmt,
-                              SLP_TREE_VECTYPE (node));
+      gimple_set_bb (call_stmt, gimple_bb (stmt_info->stmt));
+      STMT_VINFO_VECTYPE (call_stmt_info) = SLP_TREE_VECTYPE (node);
       STMT_VINFO_SLP_VECT_ONLY_PATTERN (call_stmt_info) = true;

       /* Since we are replacing all the statements in the group with the same

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[tnfchris at gcc dot gnu.org]

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

--- Comment #13 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Arseny Solokha from comment #10)
> (In reply to Tamar Christina from comment #9)
> > I wonder if whatever you're compiling is open source.  I'd love to fix some
> > of these cases properly in GCC 12.
> 
> These Fortran snippets I've been filing this week are from SCALAPACK 2.0.2
> as found on Netlib[1].
> 
> [1] https://www.netlib.org/scalapack

Thanks! This looks like a useful target to improve this with in GCC 12.  But am
I missing an option here?:

CC=~/gcc-base/install/bin/gcc \
FC=~/gcc-base/install/bin/gfortran \
CXX=~/gcc-base/install/bin/g++ \
CFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
CXXFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
FFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
cmake .. && make -j

I can't seem to get it to trigger the crash (or even detect the pattern).

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[tnfchris at gcc dot gnu.org]

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

--- Comment #14 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> Btw, the following also works as a fix but obviously I'm not in a position
> to fully evaluate this.  That said, hybrid SLP detection was rewritten during
> SLP pattern development so the requirement to hook things up as regular
> pattern might no longer be there.
> 
> Tamar - can you fully test this on aarch64?  I see the testcase from this
> PR being hybrid vectorized appropriately then.
> 

Done, testsuite and local tests are clean :)

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[asolokha at gmx dot com]

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

--- Comment #15 from Arseny Solokha <asolokha at gmx dot com> ---
(In reply to Tamar Christina from comment #13)
> (In reply to Arseny Solokha from comment #10)
> > (In reply to Tamar Christina from comment #9)
> > > I wonder if whatever you're compiling is open source.  I'd love to fix some
> > > of these cases properly in GCC 12.
> > 
> > These Fortran snippets I've been filing this week are from SCALAPACK 2.0.2
> > as found on Netlib[1].
> > 
> > [1] https://www.netlib.org/scalapack
> 
> Thanks! This looks like a useful target to improve this with in GCC 12.  But
> am I missing an option here?:
> 
> CC=~/gcc-base/install/bin/gcc \
> FC=~/gcc-base/install/bin/gfortran \
> CXX=~/gcc-base/install/bin/g++ \
> CFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
> CXXFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
> FFLAGS="-march=armv8.3-a -ftree-vectorize -O2" \
> cmake .. && make -j
> 
> I can't seem to get it to trigger the crash (or even detect the pattern).

I actually don't build the library as a library, I only use individual source
files in my test corpus.

I run (somewhat) automated gcc fuzz testing for several years by now. I briefly
explained it in the first paragraph of PR92115 comment 4 (and likely
elsewhere), but can discuss it in more details if so desired.

As an approximation, you can do something as simple as

> ~/scalapack-2.1.0/SRC % for i in *.f; do echo "Compiling $i"; aarch64-linux-gnu-gfortran-11.0.1 -march=armv8.3-a -O2 -ftree-vectorize -c $i; done

which gives me two instances of an ICE filed in this PR w/ the last weekly
snapshot, though my test harness works somewhat differently.

% aarch64-linux-gnu-gfortran-11.0.1 -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gfortran-11.0.1
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-linux-gnu/11.0.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/configure
--host=x86_64-pc-linux-gnu --target=aarch64-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/aarch64-linux-gnu/gcc-bin/11.0.1
--includedir=/usr/lib/gcc/aarch64-linux-gnu/11.0.1/include
--datadir=/usr/share/gcc-data/aarch64-linux-gnu/11.0.1
--mandir=/usr/share/gcc-data/aarch64-linux-gnu/11.0.1/man
--infodir=/usr/share/gcc-data/aarch64-linux-gnu/11.0.1/info
--with-gxx-include-dir=/usr/lib/gcc/aarch64-linux-gnu/11.0.1/include/g++-v11
--with-python-dir=/share/gcc-data/aarch64-linux-gnu/11.0.1/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls --enable-checking=yes
--disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch
--enable-poison-system-directories --with-sysroot=/usr/aarch64-linux-gnu
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp
--disable-libada --disable-systemtap --enable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --with-isl
--disable-isl-version-check --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210321 (experimental) (GCC)

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

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

commit r11-7822-ga29124d28253cdf603ba1977db2f09c9f233fea5
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Mar 24 12:55:16 2021 +0100

    tree-optimization/99746 - avoid confusing hybrid code

    This avoids confusing the hybrid vectorization code with SLP
    patterns by not marking SLP pattern covered stmts as patterns
    (they are marked as SLP patterns already).  This means that loop
    vectorization will vectorize the scalar stmt rather than the SLP
    pattern stmt (which it can't anyway).

    2021-03-24  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/99746
            * tree-vect-slp-patterns.c (complex_pattern::build): Do not mark
            the scalar stmt as patterned.  Instead set up required things
            manually.

            * gfortran.dg/vect/pr99746.f90: New testcase.

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

[tnfchris at gcc dot gnu.org]

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

--- Comment #18 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Arseny Solokha from comment #15)
> (In reply to Tamar Christina from comment #13)
> > (In reply to Arseny Solokha from comment #10)
> > > (In reply to Tamar Christina from comment #9)
> > > > I wonder if whatever you're compiling is open source.  I'd love to
> > I can't seem to get it to trigger the crash (or even detect the pattern).
> 
> I actually don't build the library as a library, I only use individual
> source files in my test corpus.
> 

Ahhh thanks! Will need to look at what the library is passing that's changing
the AST when built as a library.