Starting from r227844, we ICE on: $ cat ice.ii int *a; int b, c; void d () { for (int e; c; e++) switch (e) { case 0: a[e] = 1; case 1: b = 2; break; default: a[e] = 3; } } $ g++ ice.ii -fselective-scheduling2 -O2 -c -fvar-tracking-assignments cc1plus: warning: var-tracking-assignments changes selective scheduling ice.ii: In function ‘void d()’: ice.ii:17:1: internal compiler error: in code_motion_process_successors, at sel-sched.c:6393 } ^ 0xdba2f2 code_motion_process_successors ../../gcc/sel-sched.c:6390 0xdba2f2 code_motion_path_driver ../../gcc/sel-sched.c:6613 0xdb9ec7 code_motion_process_successors ../../gcc/sel-sched.c:6347 0xdb9ec7 code_motion_path_driver ../../gcc/sel-sched.c:6613 0xdba7e6 move_op ../../gcc/sel-sched.c:6704 0xdba7e6 move_exprs_to_boundary ../../gcc/sel-sched.c:5227 0xdba7e6 schedule_expr_on_boundary ../../gcc/sel-sched.c:5440 0xdbe2bb fill_insns ../../gcc/sel-sched.c:5582 0xdbfdc4 schedule_on_fences ../../gcc/sel-sched.c:7356 0xdbfdc4 sel_sched_region_2 ../../gcc/sel-sched.c:7494 0xdc1544 sel_sched_region_1 ../../gcc/sel-sched.c:7536 0xdc1544 sel_sched_region(int) ../../gcc/sel-sched.c:7637 0xdc2981 run_selective_scheduling() ../../gcc/sel-sched.c:7713 0xd9b4c5 rest_of_handle_sched2 ../../gcc/sched-rgn.c:3722 0xd9b4c5 execute ../../gcc/sched-rgn.c:3866 The commit is probably not responsible for the ICE.
Not sure which pass should be responsible for this. The test uses un-initialized variable e, which could cause undefined behavior? Also if I change the test into: int *a; int b, c; void d () { for (int e = 0; c; e++) switch (e) { case 0: a[e] = 1; case 1: b = 2; break; default: a[e] = 3; } } Then r227842 has segmentation fault too, though at different place. $ ./g++ pr80463.c -fselective-scheduling2 -O2 -c -fvar-tracking-assignments -S pr80463.c:1:0: warning: var-tracking-assignments changes selective scheduling int *a; ^ pr80463.c: In function ‘void d()’: pr80463.c:17:1: internal compiler error: Segmentation fault } ^ 0xfaf6e2 crash_signal ../../gcc/gcc/toplev.c:352 0xb043e4 bb_note(basic_block_def*) ../../gcc/gcc/cfgrtl.c:679 0xf5d4dd sel_bb_head(basic_block_def*) ../../gcc/gcc/sel-sched-ir.c:4520 0xf6c739 moveup_expr_cached ../../gcc/gcc/sel-sched.c:2528 0xf74945 move_op_ascend ../../gcc/gcc/sel-sched.c:6151 0xf75548 code_motion_path_driver ../../gcc/gcc/sel-sched.c:6653 0xf756b9 move_op ../../gcc/gcc/sel-sched.c:6709 0xf729ef move_exprs_to_boundary ../../gcc/gcc/sel-sched.c:5226 0xf73541 schedule_expr_on_boundary ../../gcc/gcc/sel-sched.c:5438 0xf739b7 fill_insns ../../gcc/gcc/sel-sched.c:5580 0xf76e23 schedule_on_fences ../../gcc/gcc/sel-sched.c:7363 0xf77308 sel_sched_region_2 ../../gcc/gcc/sel-sched.c:7501 0xf77491 sel_sched_region_1 ../../gcc/gcc/sel-sched.c:7543 0xf778e4 sel_sched_region(int) ../../gcc/gcc/sel-sched.c:7644 0xf779fe run_selective_scheduling() ../../gcc/gcc/sel-sched.c:7720 0xf50167 rest_of_handle_sched2 ../../gcc/gcc/sched-rgn.c:3628 0xf50340 execute ../../gcc/gcc/sched-rgn.c:3772 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
It would be related to selective scheduling pass. Testing your fixed test-case, I see ICE starting from GCC 4.8.0. GCC 4.5.0 works, and in between I see probably an infinite recursion.
I've debugged this one a bit on a revision with an ICE. We fail to move up a bookkeeping copy of a debug insn because of a piece of code in sched-deps.c: 3094 /* Quite often, a debug insn will refer to stuff in the 3095 previous instruction, but the reason we want this 3096 dependency here is to make sure the scheduler doesn't 3097 gratuitously move a debug insn ahead. This could dirty 3098 DF flags and cause additional analysis that wouldn't have 3099 occurred in compilation without debug insns, and such 3100 additional analysis can modify the generated code. */ 3101 prev = PREV_INSN (insn); 3102 3103 if (prev && NONDEBUG_INSN_P (prev) 3104 add_dependence (insn, prev, REG_DEP_ANTI); The initial insn didn't have this dependence because it was the first in block. We could either switch off this conditional completely for selective scheduling or pass there the insn through which we try to move our debug insn to be used as prev instead of completely bogus prev insn. The former is much simple because var-tracking doesn't play well with sel-sched anyways. However, while experimenting with these I have found an issue with the scheduler creating bookkeeping blocks such that the hot/cold partitioning breaks. This one should be fixed first hopefully after some discussions with Honza at the cauldron.
GCC 5 branch is being closed
Any progress with this?
(In reply to Jakub Jelinek from comment #5) > Any progress with this? I can make a patch for the dependency problem. I'm not sure what happened to the hot/cold block partitioning verification code -- I've heard Honza was going to remove it (or I have misinterpreted what Alex told me). It is unrelated to the dependence issue but is serious enough -- it's didn't allow me to test with sel-sched enabled at the time.
CCing Honza.
I cannot reproduce it anymore w/ r256677.
Seems this doesn't ICE starting with r248863, so it likely just went latent. Maybe we should just error out on selective scheduling and explicit -fvar-tracking-assignments or -gstatement-frontiers, this scheduler really can't handle any debug insns well.
(In reply to Jakub Jelinek from comment #9) > Seems this doesn't ICE starting with r248863, so it likely just went latent. I've seen ICEs in code_motion_process_successors() or bb_note() recently, will try to bring one soon.
How about this one? It makes only trunk gcc ICE, though. short int t2; int cd, aa, ft; void dh (void) { int qs = 0; if (t2 < 1) { int bq = 0; while (bq < 1) { } while (t2 < 1) { if (t2 == 0) { bq = 0; cd = !!cd; } else { bq = 1; cd = bq > qs; } t2 += cd; bq = (t2 / qs) == bq; if (aa != ft) { qs %= 0; while (bq != 0) { ro: ; } } ++t2; } ia: goto ro; } goto ia; } % gcc-8.0.0-alpha20180114 -O2 -fvar-tracking-assignments -fselective-scheduling2 -ftree-loop-vectorize -fnon-call-exceptions -fno-tree-vrp -fno-gcse-lm -fno-tree-loop-im -fno-reorder-blocks-and-partition -fno-reorder-blocks -fno-move-loop-invariants -w -c rsd2aiem.c during RTL pass: sched2 rsd2aiem.c: In function 'dh': rsd2aiem.c:51:1: internal compiler error: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.c:3622 } ^ 0x64ad85 av_set_could_be_blocked_by_bookkeeping_p /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:3622 0x64ad85 code_motion_process_successors /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6395 0x64ad85 code_motion_path_driver /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6617 0xc59886 code_motion_process_successors /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6351 0xc59886 code_motion_path_driver /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6617 0xc59886 code_motion_process_successors /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6351 0xc59886 code_motion_path_driver /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:6617 0xc5aa5a find_used_regs /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:3283 0xc5aa5a collect_unavailable_regs_from_bnds /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:1598 0xc5aa5a find_best_reg_for_expr /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:1661 0xc5aa5a fill_vec_av_set /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:3797 0xc5da87 fill_ready_list /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:4027 0xc5da87 find_best_expr /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:4387 0xc5da87 fill_insns /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:5544 0xc5da87 schedule_on_fences /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7361 0xc5da87 sel_sched_region_2 /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7499 0xc61737 sel_sched_region_1 /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7541 0xc61737 sel_sched_region(int) /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7642 0xc627a8 run_selective_scheduling() /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sel-sched.c:7718 0xc42625 rest_of_handle_sched2 /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/sched-rgn.c:3729 (as of r256677)
(In reply to Arseny Solokha from comment #11) > How about this one? It makes only trunk gcc ICE, though. > > short int t2; > int cd, aa, ft; > > void > dh (void) > { > int qs = 0; > > if (t2 < 1) > { > int bq = 0; > > while (bq < 1) > { > } > > while (t2 < 1) > { > if (t2 == 0) > { > bq = 0; > cd = !!cd; > } > else > { > bq = 1; > cd = bq > qs; > } > > t2 += cd; > bq = (t2 / qs) == bq; > > if (aa != ft) > { > qs %= 0; > while (bq != 0) > { > ro: > ; > } > } > > ++t2; > } > > ia: > goto ro; > } > > goto ia; > } > > % gcc-8.0.0-alpha20180114 -O2 -fvar-tracking-assignments > -fselective-scheduling2 -ftree-loop-vectorize -fnon-call-exceptions > -fno-tree-vrp -fno-gcse-lm -fno-tree-loop-im > -fno-reorder-blocks-and-partition -fno-reorder-blocks > -fno-move-loop-invariants -w -c rsd2aiem.c > during RTL pass: sched2 > rsd2aiem.c: In function 'dh': > rsd2aiem.c:51:1: internal compiler error: in > av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.c:3622 > } > ^ > 0x64ad85 av_set_could_be_blocked_by_bookkeeping_p > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:3622 > 0x64ad85 code_motion_process_successors > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:6395 > 0x64ad85 code_motion_path_driver > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:6617 > 0xc59886 code_motion_process_successors > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:6351 > 0xc59886 code_motion_path_driver > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:6617 > 0xc59886 code_motion_process_successors > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:6351 > 0xc59886 code_motion_path_driver > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:6617 > 0xc5aa5a find_used_regs > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:3283 > 0xc5aa5a collect_unavailable_regs_from_bnds > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:1598 > 0xc5aa5a find_best_reg_for_expr > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:1661 > 0xc5aa5a fill_vec_av_set > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:3797 > 0xc5da87 fill_ready_list > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:4027 > 0xc5da87 find_best_expr > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:4387 > 0xc5da87 fill_insns > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:5544 > 0xc5da87 schedule_on_fences > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:7361 > 0xc5da87 sel_sched_region_2 > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:7499 > 0xc61737 sel_sched_region_1 > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:7541 > 0xc61737 sel_sched_region(int) > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:7642 > 0xc627a8 run_selective_scheduling() > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sel-sched.c:7718 > 0xc42625 rest_of_handle_sched2 > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > sched-rgn.c:3729 > > (as of r256677) Give me a few more days for unrelated stuff and I'll have enough time to look at this. If that turns to be the same dependence issue, we can check in a patch without waiting for hot/cold bbs issue to be sorted out.
(In reply to Andrey Belevantsev from comment #12) > (In reply to Arseny Solokha from comment #11) > > How about this one? It makes only trunk gcc ICE, though. > > > > short int t2; > > int cd, aa, ft; > > > > void > > dh (void) > > { > > int qs = 0; > > > > if (t2 < 1) > > { > > int bq = 0; > > > > while (bq < 1) > > { > > } > > > > while (t2 < 1) > > { > > if (t2 == 0) > > { > > bq = 0; > > cd = !!cd; > > } > > else > > { > > bq = 1; > > cd = bq > qs; > > } > > > > t2 += cd; > > bq = (t2 / qs) == bq; > > > > if (aa != ft) > > { > > qs %= 0; > > while (bq != 0) > > { > > ro: > > ; > > } > > } > > > > ++t2; > > } > > > > ia: > > goto ro; > > } > > > > goto ia; > > } > > > > % gcc-8.0.0-alpha20180114 -O2 -fvar-tracking-assignments > > -fselective-scheduling2 -ftree-loop-vectorize -fnon-call-exceptions > > -fno-tree-vrp -fno-gcse-lm -fno-tree-loop-im > > -fno-reorder-blocks-and-partition -fno-reorder-blocks > > -fno-move-loop-invariants -w -c rsd2aiem.c > > during RTL pass: sched2 > > rsd2aiem.c: In function 'dh': > > rsd2aiem.c:51:1: internal compiler error: in > > av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.c:3622 > > } > > ^ > > 0x64ad85 av_set_could_be_blocked_by_bookkeeping_p > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:3622 > > 0x64ad85 code_motion_process_successors > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:6395 > > 0x64ad85 code_motion_path_driver > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:6617 > > 0xc59886 code_motion_process_successors > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:6351 > > 0xc59886 code_motion_path_driver > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:6617 > > 0xc59886 code_motion_process_successors > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:6351 > > 0xc59886 code_motion_path_driver > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:6617 > > 0xc5aa5a find_used_regs > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:3283 > > 0xc5aa5a collect_unavailable_regs_from_bnds > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:1598 > > 0xc5aa5a find_best_reg_for_expr > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:1661 > > 0xc5aa5a fill_vec_av_set > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:3797 > > 0xc5da87 fill_ready_list > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:4027 > > 0xc5da87 find_best_expr > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:4387 > > 0xc5da87 fill_insns > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:5544 > > 0xc5da87 schedule_on_fences > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:7361 > > 0xc5da87 sel_sched_region_2 > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:7499 > > 0xc61737 sel_sched_region_1 > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:7541 > > 0xc61737 sel_sched_region(int) > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:7642 > > 0xc627a8 run_selective_scheduling() > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sel-sched.c:7718 > > 0xc42625 rest_of_handle_sched2 > > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/ > > sched-rgn.c:3729 > > > > (as of r256677) > > Give me a few more days for unrelated stuff and I'll have enough time to > look at this. If that turns to be the same dependence issue, we can check > in a patch without waiting for hot/cold bbs issue to be sorted out. So this one is unrelated to the original testcase. What happens is we have a usual if then else control flow like this: bb 4 --> bb 5, bb 6; bb 5 --> bb 7; bb 6 --> bb 7. There is a debug stmt in bb 6 sayng bq is 1. We end up moving all stuff from bb 6 upwards. Without debug insns, bb 6 is about to be empty, cfg simplifications in tidy_control_flow detect this and remove a jump from bb 5 to bb 7. However, when we do have them, there is a code that tries to mimic the nondebug behavior and still removes the jump, but the block 6 itself is not removed (it still has a debug insn). So now we have bb 5 --> bb 6 edge and the scheduler crashes because the insns that were available at bb 6 suddenly become unavailable (basically they have DFS numbers that are less than those of bb 5 and we do not go in that direction). I can fix this by restoring the proper DFS numbers (seqnos) for this case, something along the lines of: diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c index a965d2ec42f..7b54f7f92d4 100644 --- a/gcc/sel-sched-ir.c +++ b/gcc/sel-sched-ir.c @@ -3890,6 +3890,17 @@ tidy_control_flow (basic_block xbb, bool full_tidying) gcc_assert (EDGE_SUCC (xbb->prev_bb, 0)->flags & EDGE_FALLTHRU); + if (MAY_HAVE_DEBUG_INSNS && (sel_bb_head (xbb) != first || sel_bb_end (xbb) != last)) + { + if (!sel_bb_empty_p (xbb->prev_bb)) + { + int prev_seqno = INSN_SEQNO (sel_bb_end (xbb->prev_bb)); + if (prev_seqno > INSN_SEQNO (sel_bb_head (xbb))) + for (insn_t insn = sel_bb_head (xbb); insn != first; insn = NEXT_INSN (insn)) + INSN_SEQNO (insn) = prev_seqno + 1; + } + } + /* It can turn out that after removing unused jump, basic block that contained that jump, becomes empty too. In such case remove it too. */ However the remaining debug insn is completely bogus at this point. Should I reset it and if so, how? The Haifa scheduler does INSN_VAR_LOCATION_LOC (dbg) = gen_rtx_UNKNOWN_VAR_LOC (); and the frees the reg use list. Or should I remove the whole bb as it would be in the non-debug insn case?
Thank you for the analysis. I can fill a separate PR for this testcase if that's more appropriate. Meanwhile, I got two more testcases which I've just reported as PR83972 and PR83973 not to clutter this PR too much, though both of them may be actually duplicates of this one.
Author: abel Date: Mon Apr 9 10:19:50 2018 New Revision: 259231 URL: https://gcc.gnu.org/viewcvs?rev=259231&root=gcc&view=rev Log: PR rtl-optimization/80463 PR rtl-optimization/83972 PR rtl-optimization/83480 * sel-sched-ir.c (has_dependence_note_mem_dep): Take into account the correct producer for the insn. (tidy_control_flow): Fixup seqnos in case of debug insns. * gcc.dg/pr80463.c: New test. * g++.dg/pr80463.C: Likewise. * gcc.dg/pr83972.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/pr80463.C trunk/gcc/testsuite/gcc.dg/pr80463.c trunk/gcc/testsuite/gcc.dg/pr83972.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
Fixed on the trunk.
Author: jakub Date: Mon Apr 9 18:21:03 2018 New Revision: 259249 URL: https://gcc.gnu.org/viewcvs?rev=259249&root=gcc&view=rev Log: PR rtl-optimization/80463 * g++.dg/pr80463.C: Add -w to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/pr80463.C
GCC 6 branch is being closed
Fixed in GCC 8.