Using cross-compiler one can see after Alexander's commit r253295: $ ppc64-linux-gnu-gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr56195.c -Ofast -fselective-scheduling /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr56195.c: In function ‘fn’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr56195.c:31:1: error: qsort comparator non-negative on sorted output: 2 } ^ during RTL pass: sched1 /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr56195.c:31:1: internal compiler error: qsort checking failed 0x57afe6 qsort_chk_error .././../gcc/vec.c:222 0x128f3b5 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) .././../gcc/vec.c:274 0xb11ca3 vec<_expr*, va_heap, vl_embed>::qsort(int (*)(void const*, void const*)) .././../gcc/vec.h:973 0xb11ca3 vec<_expr*, va_heap, vl_ptr>::qsort(int (*)(void const*, void const*)) .././../gcc/vec.h:1735 0xb11ca3 fill_vec_av_set .././../gcc/sel-sched.c:3725 0xb14493 fill_ready_list .././../gcc/sel-sched.c:4022 0xb14493 find_best_expr .././../gcc/sel-sched.c:4382 0xb14493 fill_insns .././../gcc/sel-sched.c:5539 0xb165b0 schedule_on_fences .././../gcc/sel-sched.c:7356 0xb165b0 sel_sched_region_2 .././../gcc/sel-sched.c:7494 0xb18ae1 sel_sched_region_1 .././../gcc/sel-sched.c:7536 0xb18ae1 sel_sched_region(int) .././../gcc/sel-sched.c:7637 0xb190c9 run_selective_scheduling() .././../gcc/sel-sched.c:7713 0xaf182d rest_of_handle_sched .././../gcc/sched-rgn.c:3715 0xaf182d execute .././../gcc/sched-rgn.c:3825
This is probably the same bug (on ia64): FAIL: gcc.c-torture/execute/pr57861.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) /usr/local/gcc/gcc-20171002/gcc/testsuite/gcc.c-torture/execute/pr57861.c:33:1: error: qsort comparator non-negative on sorted output: 1 during RTL pass: mach /usr/local/gcc/gcc-20171002/gcc/testsuite/gcc.c-torture/execute/pr57861.c:33:1: internal compiler error: qsort checking failed 0x40000000001b2d9f qsort_chk_error ../../gcc/vec.c:222 0x400000000209cecf qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) ../../gcc/vec.c:274 0x4000000001015d9f vec<_expr*, va_heap, vl_embed>::qsort(int (*)(void const*, void const*)) ../../gcc/vec.h:973 0x4000000001015d9f vec<_expr*, va_heap, vl_ptr>::qsort(int (*)(void const*, void const*)) ../../gcc/vec.h:1735 0x4000000001015d9f fill_vec_av_set ../../gcc/sel-sched.c:3725 0x400000000101be4f fill_ready_list ../../gcc/sel-sched.c:4022 0x400000000101be4f find_best_expr ../../gcc/sel-sched.c:4382 0x400000000101be4f fill_insns ../../gcc/sel-sched.c:5539 0x400000000101be4f schedule_on_fences ../../gcc/sel-sched.c:7356 0x400000000101be4f sel_sched_region_2 ../../gcc/sel-sched.c:7494 0x40000000010252cf sel_sched_region_1 ../../gcc/sel-sched.c:7536 0x40000000010252cf sel_sched_region(int) ../../gcc/sel-sched.c:7637 0x400000000102666f run_selective_scheduling() ../../gcc/sel-sched.c:7713 0x400000000190fd7f ia64_reorg ../../gcc/config/ia64/ia64.c:9854 0x4000000000f85acf execute ../../gcc/reorg.c:3947
This might be a typo in treatment of EXPR_USEFULNESS in comparator, adding Andrey. Tentative patch: diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c index 87a483a231e..88d8c50b508 100644 --- a/gcc/sel-sched.c +++ b/gcc/sel-sched.c @@ -3369,6 +3369,8 @@ sel_rank_for_schedule (const void *x, const void *y) if (VINSN_UNIQUE_P (tmp_vinsn) && VINSN_UNIQUE_P (tmp2_vinsn)) return SCHED_GROUP_P (tmp2_insn) ? 1 : -1; + gcc_checking_assert (VINSN_UNIQUE_P (tmp_vinsn) + || VINSN_UNIQUE_P (tmp2_vinsn)); /* Now uniqueness means SCHED_GROUP_P is set, because schedule groups cannot be cloned. */ if (VINSN_UNIQUE_P (tmp2_vinsn)) @@ -3397,7 +3399,7 @@ sel_rank_for_schedule (const void *x, const void *y) return 1; /* Prefer an expr with greater priority. */ - if (EXPR_USEFULNESS (tmp) != 0 && EXPR_USEFULNESS (tmp2) != 0) + if (EXPR_USEFULNESS (tmp) != 0 || EXPR_USEFULNESS (tmp2) != 0) { int p2 = EXPR_PRIORITY (tmp2) + EXPR_PRIORITY_ADJ (tmp2), p1 = EXPR_PRIORITY (tmp) + EXPR_PRIORITY_ADJ (tmp);
Andrey, any progress on this?
(In reply to Jakub Jelinek from comment #3) > Andrey, any progress on this? Sorry, I have somehow missed this PR. The second hunk of Alexander's patch looks fine. In the first I would rather rewrite the condition to use SCHED_GROUP_P's instead of adding an assert. We'll talk this over today and send a patch.
Author: amonakov Date: Wed Dec 13 16:30:29 2017 New Revision: 255607 URL: https://gcc.gnu.org/viewcvs?rev=255607&root=gcc&view=rev Log: sel-sched: fix sel_rank_for_schedule for qsort (PR 82398) PR rtl-optimization/82398 * sel-sched.c (sel_rank_for_schedule): Fix check for zero EXPR_USEFULNESS in priority comparison. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c
So fixed? Or do you want to keep it open for some reason (and if yes, does it have to be tracked as regression)?
Yes, fixed. I prefer to close this bug (I guess we don't want to adjust SCHED_GROUP_P handling in stage3).