* [Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305
2023-11-06 11:20 [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
@ 2023-11-06 13:11 ` rguenth at gcc dot gnu.org
2023-11-07 11:23 ` tnfchris at gcc dot gnu.org
` (24 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-11-06 13:11 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305
2023-11-06 11:20 [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
2023-11-06 13:11 ` [Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on " rguenth at gcc dot gnu.org
@ 2023-11-07 11:23 ` tnfchris at gcc dot gnu.org
2023-11-07 21:38 ` cvs-commit at gcc dot gnu.org
` (23 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-07 11:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305
2023-11-06 11:20 [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
2023-11-06 13:11 ` [Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on " rguenth at gcc dot gnu.org
2023-11-07 11:23 ` tnfchris at gcc dot gnu.org
@ 2023-11-07 21:38 ` cvs-commit at gcc dot gnu.org
2023-11-08 7:00 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-07 21:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305
2023-11-06 11:20 [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
` (2 preceding siblings ...)
2023-11-07 21:38 ` cvs-commit at gcc dot gnu.org
@ 2023-11-08 7:00 ` rguenth at gcc dot gnu.org
2023-11-08 7:02 ` tnfchris at gcc dot gnu.org
` (21 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-11-08 7:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305
2023-11-06 11:20 [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
` (3 preceding siblings ...)
2023-11-08 7:00 ` rguenth at gcc dot gnu.org
@ 2023-11-08 7:02 ` tnfchris at gcc dot gnu.org
2023-11-08 10:24 ` tnfchris at gcc dot gnu.org
` (20 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-08 7:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305
2023-11-06 11:20 [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
` (4 preceding siblings ...)
2023-11-08 7:02 ` tnfchris at gcc dot gnu.org
@ 2023-11-08 10:24 ` tnfchris at gcc dot gnu.org
2023-11-08 10:25 ` [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
` (19 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-08 10:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (5 preceding siblings ...)
2023-11-08 10:24 ` tnfchris at gcc dot gnu.org
@ 2023-11-08 10:25 ` tnfchris at gcc dot gnu.org
2023-11-08 10:40 ` rdapp at gcc dot gnu.org
` (18 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-08 10:25 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (6 preceding siblings ...)
2023-11-08 10:25 ` [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
@ 2023-11-08 10:40 ` rdapp at gcc dot gnu.org
2023-11-08 11:06 ` rdapp at gcc dot gnu.org
` (17 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-08 10:40 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (7 preceding siblings ...)
2023-11-08 10:40 ` rdapp at gcc dot gnu.org
@ 2023-11-08 11:06 ` rdapp at gcc dot gnu.org
2023-11-08 11:24 ` rdapp at gcc dot gnu.org
` (16 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-08 11:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (8 preceding siblings ...)
2023-11-08 11:06 ` rdapp at gcc dot gnu.org
@ 2023-11-08 11:24 ` rdapp at gcc dot gnu.org
2023-11-08 15:50 ` tnfchris at gcc dot gnu.org
` (15 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-08 11:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (9 preceding siblings ...)
2023-11-08 11:24 ` rdapp at gcc dot gnu.org
@ 2023-11-08 15:50 ` tnfchris at gcc dot gnu.org
2023-11-08 15:54 ` rdapp at gcc dot gnu.org
` (14 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-08 15:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (10 preceding siblings ...)
2023-11-08 15:50 ` tnfchris at gcc dot gnu.org
@ 2023-11-08 15:54 ` rdapp at gcc dot gnu.org
2023-11-17 20:35 ` cvs-commit at gcc dot gnu.org
` (13 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-08 15:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (11 preceding siblings ...)
2023-11-08 15:54 ` rdapp at gcc dot gnu.org
@ 2023-11-17 20:35 ` cvs-commit at gcc dot gnu.org
2023-11-20 9:23 ` cvs-commit at gcc dot gnu.org
` (12 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-17 20:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (12 preceding siblings ...)
2023-11-17 20:35 ` cvs-commit at gcc dot gnu.org
@ 2023-11-20 9:23 ` cvs-commit at gcc dot gnu.org
2023-11-21 4:45 ` tnfchris at gcc dot gnu.org
` (11 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-20 9:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (13 preceding siblings ...)
2023-11-20 9:23 ` cvs-commit at gcc dot gnu.org
@ 2023-11-21 4:45 ` tnfchris at gcc dot gnu.org
2023-11-21 7:38 ` rdapp at gcc dot gnu.org
` (10 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-21 4:45 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (14 preceding siblings ...)
2023-11-21 4:45 ` tnfchris at gcc dot gnu.org
@ 2023-11-21 7:38 ` rdapp at gcc dot gnu.org
2023-11-21 9:07 ` tnfchris at gcc dot gnu.org
` (9 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-21 7:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (15 preceding siblings ...)
2023-11-21 7:38 ` rdapp at gcc dot gnu.org
@ 2023-11-21 9:07 ` tnfchris at gcc dot gnu.org
2023-11-21 9:33 ` rdapp at gcc dot gnu.org
` (8 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-21 9:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (16 preceding siblings ...)
2023-11-21 9:07 ` tnfchris at gcc dot gnu.org
@ 2023-11-21 9:33 ` rdapp at gcc dot gnu.org
2023-11-21 10:29 ` rdapp at gcc dot gnu.org
` (7 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-21 9:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (17 preceding siblings ...)
2023-11-21 9:33 ` rdapp at gcc dot gnu.org
@ 2023-11-21 10:29 ` rdapp at gcc dot gnu.org
2023-11-21 10:51 ` tnfchris at gcc dot gnu.org
` (6 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-21 10:29 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (18 preceding siblings ...)
2023-11-21 10:29 ` rdapp at gcc dot gnu.org
@ 2023-11-21 10:51 ` tnfchris at gcc dot gnu.org
2023-11-21 11:22 ` rdapp at gcc dot gnu.org
` (5 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-21 10:51 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (19 preceding siblings ...)
2023-11-21 10:51 ` tnfchris at gcc dot gnu.org
@ 2023-11-21 11:22 ` rdapp at gcc dot gnu.org
2023-11-21 11:40 ` rdapp at gcc dot gnu.org
` (4 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-21 11:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (20 preceding siblings ...)
2023-11-21 11:22 ` rdapp at gcc dot gnu.org
@ 2023-11-21 11:40 ` rdapp at gcc dot gnu.org
2023-11-21 20:11 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-21 11:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (21 preceding siblings ...)
2023-11-21 11:40 ` rdapp at gcc dot gnu.org
@ 2023-11-21 20:11 ` cvs-commit at gcc dot gnu.org
2023-11-23 12:08 ` tnfchris at gcc dot gnu.org
` (2 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-11-21 20:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (22 preceding siblings ...)
2023-11-21 20:11 ` cvs-commit at gcc dot gnu.org
@ 2023-11-23 12:08 ` tnfchris at gcc dot gnu.org
2023-12-02 19:20 ` pinskia at gcc dot gnu.org
2023-12-03 19:04 ` cvs-commit at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2023-11-23 12:08 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (23 preceding siblings ...)
2023-11-23 12:08 ` tnfchris at gcc dot gnu.org
@ 2023-12-02 19:20 ` pinskia at gcc dot gnu.org
2023-12-03 19:04 ` cvs-commit at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-02 19:20 UTC (permalink / raw)
To: gcc-bugs
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'
^ permalink raw reply [flat|nested] 27+ messages in thread
* [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
2023-11-06 11:20 [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
` (24 preceding siblings ...)
2023-12-02 19:20 ` pinskia at gcc dot gnu.org
@ 2023-12-03 19:04 ` cvs-commit at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-03 19:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread