[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #25 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4c0dc30099d39ef6d1b6c8c81418c726aa660768 commit r14-6096-g4c0dc30099d39ef6d1b6c8c81418c726aa660768 Author: Jakub Jelinek 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 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.
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #24 from Andrew Pinski --- (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 '' 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 Tamar Christina changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Tamar Christina --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #22 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:2bbc7f4ef6329df62146fd6d0da5f30750cc72b4 commit r14-5697-g2bbc7f4ef6329df62146fd6d0da5f30750cc72b4 Author: Robin Dapp 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #21 from Robin Dapp --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #20 from Robin Dapp --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #19 from Tamar Christina --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #18 from Robin Dapp --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #17 from Robin Dapp --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #16 from Tamar Christina ---
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() {
| ^~
0xa9fc2e0f __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
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #15 from Robin Dapp --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #14 from Tamar Christina --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #13 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:f25a5b199a0ebd4695466e665e49041339f0c6a7 commit r14-5614-gf25a5b199a0ebd4695466e665e49041339f0c6a7 Author: Robin Dapp 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 = () _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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #12 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:231bb992592a9e1bd7ce6583131acb1874c8e34e commit r14-5564-g231bb992592a9e1bd7ce6583131acb1874c8e34e Author: Robin Dapp 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #11 from Robin Dapp --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #10 from Tamar Christina --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #9 from Robin Dapp --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #8 from Robin Dapp --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #7 from Robin Dapp ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 Tamar Christina 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
