[Bug middle-end/112406] New: [14 Regression] Several SPECCPU 2017 benchmarks fail with internal compiler error: in expand_insn, at optabs.cc:8305

[Bug middle-end/112406] New: [14 Regression] Several SPECCPU 2017 benchmarks fail with internal compiler error: in expand_insn, at optabs.cc:8305

[tnfchris at gcc dot gnu.org]

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

            Bug ID: 112406
           Summary: [14 Regression] Several SPECCPU 2017 benchmarks fail
                    with internal compiler error: in expand_insn, at
                    optabs.cc:8305
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64*

blender, wrf, imagick and fotonik in SPECCPU 2017 all fail with:

blender/source/blender/blenkernel/intern/curve.c:1403:8: internal compiler
error: in expand_insn, at optabs.cc:8305
 1403 | float *BKE_curve_surf_make_orco(Object *ob)
      |        ^
0x76681f expand_insn(insn_code, unsigned int, expand_operand*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/optabs.cc:8305
0xb43ac3 expand_insn(insn_code, unsigned int, expand_operand*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/optabs.cc:8274
0x9f0fd7 expand_fn_using_insn
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/internal-fn.cc:260
0x80026b expand_call_stmt
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:2737
0x80026b expand_gimple_stmt_1
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:3880
0x80026b expand_gimple_stmt
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:4044
0x804917 expand_gimple_basic_block
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:6100
0x8065c7 execute
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:6835

Will reduce and bisect...

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Possibly the same as PR112359?

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305

[tnfchris at gcc dot gnu.org]

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

--- Comment #2 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Possibly the same as PR112359?

Some were yeah, looks like there are still 2 ICEs in imagick and exchange, I'll
start reducing those.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

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

commit r14-5231-gfd940d248bfccb6994794152681dc4c693160919
Author: Robin Dapp <rdapp@ventanamicro.com>
Date:   Mon Nov 6 11:24:37 2023 +0100

    vect/ifcvt: Add vec_cond fallback and check for vector versioning.

    This restricts tree-ifcvt to only create COND_OPs when we versioned the
    loop for vectorization.  Apart from that it re-creates a VEC_COND_EXPR
    in vect_expand_fold_left if we emitted a COND_OP.

    gcc/ChangeLog:

            PR tree-optimization/112361
            PR target/112359
            PR middle-end/112406

            * tree-if-conv.cc (convert_scalar_cond_reduction): Remember if
            loop was versioned and only then create COND_OPs.
            (predicate_scalar_phi): Do not create COND_OP when not
            vectorizing.
            * tree-vect-loop.cc (vect_expand_fold_left): Re-create
            VEC_COND_EXPR.
            (vectorize_fold_left_reduction): Pass mask to
            vect_expand_fold_left.

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr112359.c: New test.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305

[tnfchris at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-11-08
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
No, ICE is still there on imagick and on exchange it's changed to

during GIMPLE pass: vect
exchange2.fppized.f90: In function 'digits_2.isra':
exchange2.fppized.f90:998:31: internal compiler error: in
vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1257
  998 |   recursive subroutine digits_2(row)
      |                               ^
0x1813b6b vect_get_vec_defs_for_operand(vec_info*, _stmt_vec_info*, unsigned
int, tree_node*, vec<tree_node*, va_heap, vl_ptr>*, tree_node*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-stmts.cc:1257
0x1813ceb vect_get_vec_defs(vec_info*, _stmt_vec_info*, _slp_tree*, unsigned
int, tree_node*, vec<tree_node*, va_heap, vl_ptr>*, tree_node*, tree_node*,
vec<tree_node*, va_heap, vl_ptr>*, tree_node*, tree_node*, vec<tree_node*,
va_heap, vl_ptr>*, tree_node*, tree_node*, vec<tree_node*, va_heap, vl_ptr>*,
tree_node*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-stmts.cc:1289
0x1813dcf vect_get_vec_defs(vec_info*, _stmt_vec_info*, _slp_tree*, unsigned
int, tree_node*, vec<tree_node*, va_heap, vl_ptr>*, tree_node*, vec<tree_node*,
va_heap, vl_ptr>*, tree_node*, vec<tree_node*, va_heap, vl_ptr>*, tree_node*,
vec<tree_node*, va_heap, vl_ptr>*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-stmts.cc:1311
0xea9bc3 vect_transform_reduction(_loop_vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, gimple**, _slp_tree*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:8470
0x18311fb vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-stmts.cc:13100
0xe9a223 vect_transform_loop_stmt
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:11322
0xeb79ff vect_transform_loop(_loop_vec_info*, gimple*)
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:11774
0xeedb4b vect_transform_loops
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1006
0xeee18f try_vectorize_loop_1
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1152
0xeee18f try_vectorize_loop
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1182
0xeee40f execute
        /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1298

I'll reduce exchange first since less object files.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305

[tnfchris at gcc dot gnu.org]

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

--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
First reduction:

typedef struct {
  int red
} MagickPixelPacket;
GetImageChannelMoments_image, GetImageChannelMoments_image_0,
    GetImageChannelMoments___trans_tmp_1, GetImageChannelMoments_M11_0,
    GetImageChannelMoments_pixel_3, GetImageChannelMoments_y,
    GetImageChannelMoments_p;
double GetImageChannelMoments_M00_0, GetImageChannelMoments_M00_1,
    GetImageChannelMoments_M01_1;
MagickPixelPacket GetImageChannelMoments_pixel;
SetMagickPixelPacket(int color, MagickPixelPacket *pixel) {
  pixel->red = color;
}
GetImageChannelMoments() {
  for (; GetImageChannelMoments_y; GetImageChannelMoments_y++) {
    SetMagickPixelPacket(GetImageChannelMoments_p,
                         &GetImageChannelMoments_pixel);
    GetImageChannelMoments_M00_1 += GetImageChannelMoments_pixel.red;
    if (GetImageChannelMoments_image)
      GetImageChannelMoments_M00_1++;
    GetImageChannelMoments_M01_1 +=
        GetImageChannelMoments_y * GetImageChannelMoments_pixel_3;
    if (GetImageChannelMoments_image_0)
      GetImageChannelMoments_M00_0++;
    GetImageChannelMoments_M01_1 +=
        GetImageChannelMoments_y * GetImageChannelMoments_p++;
  }
  GetImageChannelMoments___trans_tmp_1 = atan(GetImageChannelMoments_M11_0);
}

reproduce with:

gcc -march=armv8-a+sve -w -Ofast statistic.i -o statistic.o

bisected to:

01c18f58d37865d5f3bbe93e666183b54ec608c7 is the first bad commit
commit 01c18f58d37865d5f3bbe93e666183b54ec608c7
Author: Robin Dapp <rdapp@ventanamicro.com>
Date:   Wed Sep 13 22:19:35 2023 +0200

    ifcvt/vect: Emit COND_OP for conditional scalar reduction.

    As described in PR111401 we currently emit a COND and a PLUS expression
    for conditional reductions.  This makes it difficult to combine both
    into a masked reduction statement later.
    This patch improves that by directly emitting a COND_ADD/COND_OP during
    ifcvt and adjusting some vectorizer code to handle it.

    It also makes neutral_op_for_reduction return -0 if HONOR_SIGNED_ZEROS
    is true.

    gcc/ChangeLog:

            PR middle-end/111401
            * internal-fn.cc (internal_fn_else_index): New function.
            * internal-fn.h (internal_fn_else_index): Define.
            * tree-if-conv.cc (convert_scalar_cond_reduction): Emit COND_OP
            if supported.
            (predicate_scalar_phi): Add whitespace.
            * tree-vect-loop.cc (fold_left_reduction_fn): Add IFN_COND_OP.
            (neutral_op_for_reduction): Return -0 for PLUS.
            (check_reduction_path): Don't count else operand in COND_OP.
            (vect_is_simple_reduction): Ditto.
            (vect_create_epilog_for_reduction): Fix whitespace.
            (vectorize_fold_left_reduction): Add COND_OP handling.
            (vectorizable_reduction): Don't count else operand in COND_OP.
            (vect_transform_reduction): Add COND_OP handling.
            * tree-vectorizer.h (neutral_op_for_reduction): Add default
            parameter.

    gcc/testsuite/ChangeLog:

            * gcc.dg/vect/vect-cond-reduc-in-order-2-signed-zero.c: New test.
            * gcc.target/riscv/rvv/autovec/cond/pr111401.c: New test.
            * gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c: Adjust.
            * gcc.target/riscv/rvv/autovec/reduc/reduc_call-4.c: Ditto.

--

I'll start on the exchange one now.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[tnfchris at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
            Summary|[14 Regression] Several     |[14 Regression] Several
                   |SPECCPU 2017 benchmarks     |SPECCPU 2017 benchmarks
                   |fail with LTO on internal   |fail with on internal
                   |compiler error: in          |compiler error: in
                   |expand_insn, at             |expand_insn, at
                   |optabs.cc:8305              |optabs.cc:8305 after
                   |                            |g:01c18f58d37865d5f3bbe93e6
                   |                            |66183b54ec608c7

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #7 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Ah, thanks, I can reproduce this on the cfarm/gcc185.

We don't expand:
vect__ifc__141.81_358 = .COND_ADD (vect_cst__356,
vect_GetImageChannelMoments_M00_0_lsm.74_338, { 1.0e+0, ... },
vect_GetImageChannelMoments_M00_0_lsm.74_338);

because we cannot legitimize the first operand ([1]):
 (reg:VNx16QI 247 [ vect_cst__356 ])
while operand[0] is VNx2DFmode (reg:VNx2DF 248 [ vect__ifc__141.81 ]).

We only check for the lhs type in ifcvt via vectorized_internal_fn_supported_p.
Maybe we need something like ifcvt_can_predicate as well?

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #8 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Ah of course it's not the first argument but the mask.  During vectorization we
already create

fail1.c:15:10: note:  add new stmt: vect__ifc__141.81_358 = .COND_ADD
(vect_cst__356, vect_GetImageChannelMoments_M00_0_lsm.74_338, vect_cst__357,
vect_GetImageChannelMoments_M00_0_lsm.74_338);

where vect_cst__356 is

vector([16,16]) unsigned char vect_cst__356;

fail1.c:15:10: note:  created new init_stmt: _355 = (unsigned char) _114; 
fail1.c:15:10: note:  created new init_stmt: vect_cst__356 =
[vec_duplicate_expr] _355;

The type comes from vect_get_vec_defs_for_operand.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #9 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I believe the problem is that in

      if (vectype)
        vector_type = vectype;
      else if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
               && VECTOR_BOOLEAN_TYPE_P (stmt_vectype))
        vector_type = truth_type_for (stmt_vectype);
      else
        vector_type = get_vectype_for_scalar_type (loop_vinfo, TREE_TYPE (op));

we don't expect a COND_OP and wrongly deduce the vector type from the scalar
type (because !VECTOR_BOOLEAN_TYPE_P (stmt_vectype)).  Maybe we need to check
whether we look at the mask operand of a conditional operation and use the
statement's vectype in that case.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[tnfchris at gcc dot gnu.org]

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

--- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Just finished second bisect and reduce.  Came out to this commit as well.

---

  module brute_force
    integer, parameter :: r=9
     integer sudoku1(1, r)
    contains
  subroutine brute
  integer l(r), u(r)
     where(sudoku1(1, :) /= 1)
          l = 1
        u = 1
     end where
  do i1 = 1, u(1)
     do
        end do
     end do
  end
  end

---

gfortran -w -c exchange2.f90 -fprofile-generate -march=armv8-a+sve -Ofast -o
exchange2.f90.o

gives:

during GIMPLE pass: vect
exchange2.fppized2.f90:5:18:

    5 |   subroutine brute
      |                  ^
internal compiler error: in vect_get_vec_defs_for_operand, at
tree-vect-stmts.cc:1257

which is probably related to your last message.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #11 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Thanks, this is helpful.

I have a patch that I just bootstrapped and ran the testsuite with on aarch64.
Going to post it soon, maybe Richi still has a better idea how to work around
this.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

https://gcc.gnu.org/g:231bb992592a9e1bd7ce6583131acb1874c8e34e

commit r14-5564-g231bb992592a9e1bd7ce6583131acb1874c8e34e
Author: Robin Dapp <rdapp@ventanamicro.com>
Date:   Thu Nov 16 20:42:10 2023 +0100

    vect: Pass truth type to vect_get_vec_defs.

    For conditional operations the mask is loop invariant and cannot be
    stored explicitly.  By default, for reductions, we deduce the vectype
    from the statement or the loop but this does not work for conditional
    operations.  Therefore this patch passes the truth type of the reduction
    input vectype for the mask operand instead.  This will override the
    other choices and make sure we have the proper mask vectype.

    gcc/ChangeLog:

            PR middle-end/112406
            PR middle-end/112552

            * tree-vect-loop.cc (vect_transform_reduction): Pass truth
            vectype for mask operand.

    gcc/testsuite/ChangeLog:

            * gcc.target/aarch64/pr112406.c: New test.
            * gcc.target/riscv/rvv/autovec/pr112552.c: New test.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

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

commit r14-5614-gf25a5b199a0ebd4695466e665e49041339f0c6a7
Author: Robin Dapp <rdapp@ventanamicro.com>
Date:   Fri Nov 17 10:34:35 2023 +0100

    vect: Add bool pattern handling for COND_OPs.

    In order to handle masks properly for conditional operations this patch
    teaches vect_recog_mask_conversion_pattern to also handle conditional
    operations.  Now we convert e.g.

     _mask = *_6;
     _ifc123 = COND_OP (_mask, ...);

    into
     _mask = *_6;
     patt200 = (<signed-boolean:1>) _mask;
     patt201 = COND_OP (patt200, ...);

    This way the mask will be properly recognized as boolean mask and the
    correct vector mask will be generated.

    gcc/ChangeLog:

            PR middle-end/112406

            * tree-vect-patterns.cc (vect_recog_mask_conversion_pattern):
            Convert masks for conditional operations as well.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/pr112406.f90: New test.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[tnfchris at gcc dot gnu.org]

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

--- Comment #14 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks,  Those cases seem fixed now.

I do however still see another LTO failure that looks related in SPECCPU 2006:

ratectl.c:1566:6: internal compiler error: in vect_transform_reduction, at
tree-vect-loop.cc:8458
 1566 | void RCModelEstimator (int n_windowSize)
      |      ^
0xeb0adf vect_transform_reduction(_loop_vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, gimple**, _slp_tree*)
  /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:8458
0x182840b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
  /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-stmts.cc:13085
0xe9f7d3 vect_transform_loop_stmt
  /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:11395
0xebd7c7 vect_transform_loop(_loop_vec_info*, gimple*)
  /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vect-loop.cc:11840
0xef321b vect_transform_loops
  /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1006
0xef385f try_vectorize_loop_1
  /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1152
0xef385f try_vectorize_loop
  /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1182
0xef3adf execute
  /opt/buildAgent/work/5c94c4ced6ebfcd0/gcc/tree-vectorizer.cc:1298

I will reduce and bisect this morning and will close this tickets and file a
new one if not.
Still waiting on the results of the other non SPECCPU workloads, but so far
looks good!

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #15 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Hmm, that's definitely related to the original change but most likely not to
the fixes.

      gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB
                  || code == IFN_COND_MUL || code == IFN_COND_AND
                  || code == IFN_COND_IOR || code == IFN_COND_XOR);
      gcc_assert (op.num_ops == 4 && (op.ops[1] == op.ops[3]));

The second assert fails and op.num_ops must be correct because of the first
assert.  Maybe, via LTO, we somehow propagate a constant into the else or so?
I just noticed that since we now have the internal_fn_else_index, we could use
this here as well for clarity.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[tnfchris at gcc dot gnu.org]

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

--- Comment #16 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Ah, saves me the bisect then :)

Morning, new reproducer is:

> cat ratectl.i
double MADPictureC1;
extern int PictureRejected[];
int PictureMAD_0, MADModelEstimator_n_windowSize_i,
MADModelEstimator_n_windowSize_oneSampleQ;

void MADModelEstimator_n_windowSize() {
  int estimateX2 = 0;
  for (; MADModelEstimator_n_windowSize_i; MADModelEstimator_n_windowSize_i++)
{
    if (MADModelEstimator_n_windowSize_oneSampleQ &&
        !PictureRejected[MADModelEstimator_n_windowSize_i])
      estimateX2 = 1;
    if (!PictureRejected[MADModelEstimator_n_windowSize_i])
      MADPictureC1 += PictureMAD_0;
  }
  if (estimateX2)
    for (;;)
      ;
}

----
and called with:

gcc -c -o ratectl.o -Ofast -march=armv8-a+sve  ratectl.i
during GIMPLE pass: vect
ratectl.i: In function 'MADModelEstimator_n_windowSize':
ratectl.i:5:6: internal compiler error: in vect_transform_reduction, at
tree-vect-loop.cc:8442
    5 | void MADModelEstimator_n_windowSize() {
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0xffffa9fc2e0f __libc_start_main
        ../csu/libc-start.c:308
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.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #17 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Thanks, I reproduced it on the compile farm with this example.  Going to have a
look.  riscv doesn't fail in a similar way this time.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #18 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Already in ifcvt we have:

_ifc__60 = .COND_ADD (_2, _6, MADPictureC1_lsm.10_25, MADPictureC1_lsm.10_25);

which we should not.  This is similar on riscv.

But during value numbering it still is

Value numbering stmt = _ifc__60 = .COND_ADD (_47, MADPictureC1_lsm.10_25, _6,
MADPictureC1_lsm.10_25);

so we originally created the right thing.
Hmm, no simplification is happening.  Is there still a swap somewhere that
should not be?

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[tnfchris at gcc dot gnu.org]

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

--- Comment #19 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #18)
> Already in ifcvt we have:
> 
> _ifc__60 = .COND_ADD (_2, _6, MADPictureC1_lsm.10_25,
> MADPictureC1_lsm.10_25);
> 
> which we should not.  This is similar on riscv.
> 
> But during value numbering it still is
> 
> Value numbering stmt = _ifc__60 = .COND_ADD (_47, MADPictureC1_lsm.10_25,
> _6, MADPictureC1_lsm.10_25);
> 
> so we originally created the right thing.
> Hmm, no simplification is happening.  Is there still a swap somewhere that
> should not be?

ADD is commutative, so commutative_op declares COND_ADD as commutative and the
first commutative operand starts at op1.

So swapping _6 and MADPictureC1_lsm.10_25 should be legal to do.  Are you
depending on a specific order?

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #20 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Not really depending on an order but rather expecting that the reduction
variable is in op[1] (as created by ifcvt).

That might already be the problem because here the reduction index is 2.  It
just never happened up to now that we made use of commutativity.

Going to prepare a fix.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[rdapp at gcc dot gnu.org]

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

--- Comment #21 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Grml,

../../gcc/tree-vect-loop.cc:12248:1: fatal error: error writing to
/tmp/ccsMqSV2.s: No space left on device

on cfarm185, cannot even build anymore.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:

https://gcc.gnu.org/g:2bbc7f4ef6329df62146fd6d0da5f30750cc72b4

commit r14-5697-g2bbc7f4ef6329df62146fd6d0da5f30750cc72b4
Author: Robin Dapp <rdapp@ventanamicro.com>
Date:   Tue Nov 21 12:51:12 2023 +0100

    vect: Allow reduc_index != 1 for COND_OPs.

    In PR112406 Tamar found another problem with COND_OP reductions.
    I wrongly assumed that the reduction variable will always remain in
    operand 1, just as we create the COND_OP in ifcvt.  But of course,
    addition being commutative, we are free to swap operand 1 and 2 and we
    end up with e.g.

     _ifc__60 = .COND_ADD (_2, _6, MADPictureC1_lsm.10_25,
MADPictureC1_lsm.10_25);

    which does not pass the asserts I put in place.

    This patch removes this restriction and allows the reduction index to be
    2 as well.

    gcc/ChangeLog:

            PR middle-end/112406

            * tree-vect-loop.cc (vectorize_fold_left_reduction): Allow
            reduction index != 1.
            (vect_transform_reduction): Handle reduction index != 1.

    gcc/testsuite/ChangeLog:

            * gcc.target/aarch64/pr112406-2.c: New test.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[tnfchris at gcc dot gnu.org]

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

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

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

--- Comment #23 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks! that seems to be all we've noticed.

Thanks for the quick fixes!

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[pinskia at gcc dot gnu.org]

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

--- Comment #24 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to GCC Commits from comment #22)
>     gcc/testsuite/ChangeLog:
>     
>             * gcc.target/aarch64/pr112406-2.c: New test.

This testcase now fails after the recent changes to make some warnings
defaulting to errors:
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:8:1:
error: type defaults to 'int' in declaration of 'GetImageChannelMoments_image'
[-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:8:31:
error: type defaults to 'int' in declaration of
'GetImageChannelMoments_image_0' [-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:9:5:
error: type defaults to 'int' in declaration of
'GetImageChannelMoments___trans_tmp_1' [-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:9:43:
error: type defaults to 'int' in declaration of 'GetImageChannelMoments_M11_0'
[-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:10:5:
error: type defaults to 'int' in declaration of
'GetImageChannelMoments_pixel_3' [-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:10:37:
error: type defaults to 'int' in declaration of 'GetImageChannelMoments_y'
[-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:11:5:
error: type defaults to 'int' in declaration of 'GetImageChannelMoments_p'
[-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:18:1:
error: return type defaults to 'int' [-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:22:1:
error: return type defaults to 'int' [-Wimplicit-int]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:
In function 'GetImageChannelMoments':
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:36:42:
error: implicit declaration of function 'atan'
[-Wimplicit-function-declaration]
/home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:36:42:
note: include '<math.h>' or provide a declaration of 'atan'

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #25 from GCC 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:4c0dc30099d39ef6d1b6c8c81418c726aa660768

commit r14-6096-g4c0dc30099d39ef6d1b6c8c81418c726aa660768
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sun Dec 3 20:03:27 2023 +0100

    testsuite: Fix up gcc.target/aarch64/pr112406.c for modern C [PR112406]

    On Fri, Nov 17, 2023 at 02:04:01PM +0100, Robin Dapp wrote:
    > > Yes, your version is also OK.
    >
    > The attached was bootstrapped and regtested on aarch64, x86 and
    > regtested on riscv.  Going to commit it later unless somebody objects.

    Unfortunately the aarch64/pr112406.c was reduced too much and is rejected
    since the switch to modern C patchset.

    The following patch fixes that, I've verified the testcase
    before/after the changes still ICEs in r14-5563 and doesn't with
    r14-5564 and after the changes compiles fine with even latest trunk.
    Everything admittedly with a cross-compiler, but that shouldn't change
    anything.

    Note, one of the modern C changes is that at least when people use
    cvise/creduce/delta scripts which ensure no further errors are introduced
    during the reduction then expected originally such reductions will not
    appear anymore.

    2023-12-03  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/112406
            * gcc.target/aarch64/pr112406.c (MagickPixelPacket): Add missing
            semicolon.
            (GetImageChannelMoments_image): Avoid using implicit int.
            (SetMagickPixelPacket): Use void return type instead of implicit
int.
            (GetImageChannelMoments): Likewise.  Use __builtin_atan instead of
            atan.