gcc-8.0.0-alpha20180415 snapshot (r259389) ICEs when compiling the following snippet w/ -march=haswell -O2 (-O3) -fselective-scheduling2 -fsel-sched-pipelining -fno-tree-ch -fno-tree-loop-im: int n7; int rf (double as, long int u1, int sp, int fy) { int ku = 0, us = 1, lo = sp; while (fy < 1) { const long int pg = 5; const unsigned int g5 = 3; ku = as + us; if (fy == 0) n7 /= u1; else { const long long unsigned int w7 = 3; us = 0; as = u1 / w7 + u1; } fy = sp % pg + n7 / g5; } if (ku < 1) lo = u1; return lo; } % x86_64-pc-linux-gnu-gcc-8.0.0-alpha20180415 -march=haswell -O2 -fselective-scheduling2 -fsel-sched-pipelining -fno-tree-ch -fno-tree-loop-im -c t4byfoly.c during RTL pass: sched2 t4byfoly.c: In function 'rf': t4byfoly.c:32:1: internal compiler error: in put_TImodes, at sel-sched.c:7191 } ^ 0x64f37b put_TImodes /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7191 0x64f37b sel_region_target_finish /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7238 0x64f37b sel_region_finish /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7289 0x64f37b sel_sched_region(int) /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7658 0xc6ef38 run_selective_scheduling() /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7733 0xc4e9a5 rest_of_handle_sched2 /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sched-rgn.c:3732 0xc4e9a5 execute /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sched-rgn.c:3876 I've been hitting it for a while but am filing a PR only now, when many selective scheduling fixes have actually started landing on the trunk.
Can't reproduce in my bisect seed, so can't bisect. Can reproduce with current trunk though. 7188 clock = INSN_SCHED_CYCLE (insn); 7189 cost = (last_clock == -1) ? 1 : clock - last_clock; 7190 7191 gcc_assert (cost >= 0); clock is 0, last_clock is 37, so cost is -37. Though, s_i_d array has just length of 52 and insn here (created by #1 0x0000000000acef21 in emit_insn (x=0x7fffefdfef40) at ../../gcc/emit-rtl.c:5116 #2 0x0000000000f56d77 in create_insn_rtx_from_pattern (pattern=0x7fffefdfef40, label=0x0) at ../../gcc/sel-sched-ir.c:5753 #3 0x0000000000f56f09 in create_copy_of_insn_rtx (insn_rtx=0x7fffefc58ec0) at ../../gcc/sel-sched-ir.c:5798 #4 0x0000000000f686b1 in emit_bookkeeping_insn (place_to_insert=0x7fffefe070c0, c_expr=0x7fffffffd8c0, new_seqno=100) at ../../gcc/sel-sched.c:4768 #5 0x0000000000f6881e in generate_bookkeeping_insn (c_expr=0x7fffffffd8c0, e1=<edge 0x7fffefddc600 (9 -> 4)>, e2=<edge 0x7fffefddc600 (9 -> 4)>) at ../../gcc/sel-sched.c:4805 #6 0x0000000000f6b58b in move_op_at_first_insn (insn=0x7fffefdf88c0, lparams=0x7fffffffd440, static_params=0x7fffffffd7e0) at ../../gcc/sel-sched.c:6077 #7 0x0000000000f6c2b2 in code_motion_path_driver (insn=0x7fffefdf88c0, orig_ops=0x0, path=0x2d193d0, local_params_in=0x7fffffffd440, static_params=0x7fffffffd7e0) at ../../gcc/sel-sched.c:6669 #8 0x0000000000f6bad6 in code_motion_process_successors (insn=0x7fffefdebe58, orig_ops=0x2d19f88, path=0x2d193d0, static_params=0x7fffffffd7e0) at ../../gcc/sel-sched.c:6356 #9 0x0000000000f6c199 in code_motion_path_driver (insn=0x7fffefdebe58, orig_ops=0x2d19f88, path=0x2d193d0, local_params_in=0x7fffffffd630, static_params=0x7fffffffd7e0) at ../../gcc/sel-sched.c:6622 #10 0x0000000000f6bad6 in code_motion_process_successors (insn=0x7fffefdebea0, orig_ops=0x2d1b4a0, path=0x2d1bb30, static_params=0x7fffffffd7e0) at ../../gcc/sel-sched.c:6356 #11 0x0000000000f6c199 in code_motion_path_driver (insn=0x7fffefdebea0, orig_ops=0x2d1b4a0, path=0x2d1bb30, local_params_in=0x7fffffffd7b0, static_params=0x7fffffffd7e0) at ../../gcc/sel-sched.c:6622 #12 0x0000000000f6c3af in move_op (insn=0x7fffefc58bc0, orig_ops=0x2d1b860, expr_vliw=0x2d1bef8, dest=0x0, c_expr=0x7fffffffd8c0, should_move=0x7fffffffd89a) at ../../gcc/sel-sched.c:6714 #13 0x0000000000f696eb in move_exprs_to_boundary (bnd=0x2d19360, expr_vliw=0x2d1bef8, expr_seq=0x2d1b860, c_expr=0x7fffffffd8c0) at ../../gcc/sel-sched.c:5237 #14 0x0000000000f6a24b in schedule_expr_on_boundary (bnd=0x2d19360, expr_vliw=0x2d1bef8, seqno=-13) at ../../gcc/sel-sched.c:5450 #15 0x0000000000f6a6ec in fill_insns (fence=0x2d1b598, seqno=-13, scheduled_insns_tailpp=0x7fffffffda90) at ../../gcc/sel-sched.c:5592 #16 0x0000000000f6dbbd in schedule_on_fences (fences=0x2d1a2d0, max_seqno=32, scheduled_insns_tailpp=0x7fffffffda90) at ../../gcc/sel-sched.c:7366 #17 0x0000000000f6e0ae in sel_sched_region_2 (orig_max_seqno=34) at ../../gcc/sel-sched.c:7504 #18 0x0000000000f6e22d in sel_sched_region_1 () at ../../gcc/sel-sched.c:7546 #19 0x0000000000f6e683 in sel_sched_region (rgn=0) at ../../gcc/sel-sched.c:7647 has INSN_LUID 0.
Confirmed. This also hits Itanium when building SPEC CPU 2000 with -O3 -funroll-loops -fpeel-loops in 176.gcc, 191.fma3d and 177.mesa.
This bit python3.7 as well on ia64: https://buildd.debian.org/status/fetch.php?pkg=python3.7&arch=ia64&ver=3.7.0-4&stamp=1533196157&raw=0
(In reply to Jason Duerstock from comment #3) > This bit python3.7 as well on ia64: I believe you can replace -O3 w/ -O2 as a workaround when building for IA64.
Slightly shorter reproduced (shrunk with creduce): // a.c int a, b, c; int e(int h) { double d; int f = 1; while (b < 1) { c = d + f; if (b) a /= h; else { long unsigned g; f = 0; d = h / g + h; } b = a / 3; } } // command: // x86_64-pc-linux-gnu-gcc-8.2.0 -c a.c -march=haswell -O2 -fselective-scheduling2 -fsel-sched-pipelining -fno-tree-ch -fno-tree-loop-im
The fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85354 wouldn't happen to have caused this, would it?
(In reply to Sergei Trofimovich from comment #5) > Slightly shorter reproduced (shrunk with creduce): > > // a.c > int a, b, c; > int e(int h) { > double d; > int f = 1; > while (b < 1) { > c = d + f; > if (b) > a /= h; > else { > long unsigned g; > f = 0; > d = h / g + h; > } > b = a / 3; > } > } > > // command: > // x86_64-pc-linux-gnu-gcc-8.2.0 -c a.c -march=haswell -O2 > -fselective-scheduling2 -fsel-sched-pipelining -fno-tree-ch -fno-tree-loop-im Bisected this down from gcc-7.3.0 (did not ICE) to gcc-8. Looks reasonable? 91d7a2f98a6846d6a4ac215abbbcf8e6154b9984 is the first bad commit commit 91d7a2f98a6846d6a4ac215abbbcf8e6154b9984 Author: abel <abel@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Mon Apr 9 09:08:28 2018 +0000 PR rtl-optimization/83530 * sel-sched.c (force_next_insn): New global variable. (remove_insn_for_debug): When force_next_insn is true, also leave only next insn in the ready list. (sel_sched_region): When the region wasn't scheduled, make another pass over it with force_next_insn set to 1. * gcc.dg/pr83530.c: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@259228 138bc75d-0d04-0410-961f-82ee72b054a4 :040000 040000 11825cae45f4d9839c242188123117a0a9f96803 87391fd9d4f97ee6fe456d1630f37801dc0bf8cc M gcc
Sigh. We set reset_sched_cycles_p to pipelining_p after the conditional, but we have missed that in sel_sched_region_1 pipelining_p will be set to false. So that initial patch should have the following hunk instead: diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c index 315f2c0c0ab..29d9abd7200 100644 --- a/gcc/sel-sched.c +++ b/gcc/sel-sched.c @@ -7648,11 +7648,11 @@ sel_sched_region (int rgn) /* Schedule always selecting the next insn to make the correct data for bundling or other later passes. */ pipelining_p = false; + reset_sched_cycles_p = false; force_next_insn = 1; sel_sched_region_1 (); force_next_insn = 0; } - reset_sched_cycles_p = pipelining_p; sel_region_finish (reset_sched_cycles_p); } I've checked that it fixes the ICE on the original revision, trunk doesn't ICE for me.
(In reply to Andrey Belevantsev from comment #8) > trunk doesn't > ICE for me. I don't have a good testcase at hand (it's just a matter of time, though), but at least the following snippet makes the current trunk ICE: subroutine kc (IX, L4, PQ) integer VT, DK, L4, IX, F0 real PQ (L4, L4) F0 = VT 0010 do VT = 1, 2 end do if (IX .eq. 0) go to 0020 do VT = 1, L4 end do go to 0010 0020 do VT = 1, L4 if (VT .ge. 0 .and. VT .le. F0) go to 0030 do DK = VT, L4 PQ (VT, DK) = 0.0 end do 0030 end do return end % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190317 -m32 -mcpu=970 -O1 -fschedule-insns2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fselective-scheduling2 -ftree-parallelize-loops=2 --param selsched-max-sched-times=3 -c eowqbvfn.f
(In reply to Arseny Solokha from comment #9) > (In reply to Andrey Belevantsev from comment #8) > > trunk doesn't > > ICE for me. > > I don't have a good testcase at hand (it's just a matter of time, though), > but at least the following snippet makes the current trunk ICE: > > subroutine kc (IX, L4, PQ) > > integer VT, DK, L4, IX, F0 > real PQ (L4, L4) > > F0 = VT > > 0010 do VT = 1, 2 > end do > > if (IX .eq. 0) go to 0020 > > do VT = 1, L4 > end do > > go to 0010 > > 0020 do VT = 1, L4 > if (VT .ge. 0 .and. VT .le. F0) go to 0030 > > do DK = VT, L4 > PQ (VT, DK) = 0.0 > end do > 0030 end do > > return > end > > % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190317 -m32 -mcpu=970 -O1 > -fschedule-insns2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops > -fselective-scheduling2 -ftree-parallelize-loops=2 --param > selsched-max-sched-times=3 -c eowqbvfn.f Is it easy for you to check that the above patch fixes also your testcase?
(In reply to Andrey Belevantsev from comment #10) > Is it easy for you to check that the above patch fixes also your testcase? Sure, I'll do it tomorrow.
Meanwhile, here's a C testcase that fails w/ the latest trunk snapshot on x86_64: __int128 jv; void zm (__int128 g9, unsigned short int sm, short int hk) { while (hk < 1) { if (jv == 0) sm *= g9; if (sm < jv) hk = sm; g9 |= sm == hk; } } % x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20190317 -march=bonnell -O1 -fpeephole2 -fschedule-insns2 -fsel-sched-pipelining -fselective-scheduling2 -ftree-loop-if-convert -fno-if-conversion -fno-move-loop-invariants -fno-split-wide-types -fno-tree-dominator-opts -c erji5uml.c
The patch in comment 8 fixes testcases from both comment 9 and comment 12 for me.
Author: amonakov Date: Mon Apr 1 18:05:08 2019 New Revision: 270065 URL: https://gcc.gnu.org/viewcvs?rev=270065&root=gcc&view=rev Log: sel-sched: correct reset of reset_sched_cycles_p (PR 85412) 2019-04-01 Andrey Belevantsev <abel@ispras.ru> PR rtl-optimization/85412 * sel-sched.c (sel_sched_region): Assign reset_sched_cycles_p before sel_sched_region_1, not after. * gcc.dg/pr85412.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr85412.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog
Fixed on the trunk.
GCC 9.1 has been released.
GCC 9.2 has been released.
GCC 9.3.0 has been released, adjusting target milestone.
Fixed for x86_64 on all supported branches for more than two years now. Is it fixed for IA64 too?
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
I've dropped regression marker from the PR title as it's not a regression on any of the supported branches anymore. The fix should be verified for IA64 and the PR should then be closed.
Fixed in GCC 9.