https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530

Arseny Solokha <asolokha at gmx dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #4 from Arseny Solokha <asolokha at gmx dot com> ---
gcc/sel-sched.c:7150 in r255766 became sel-sched.c:7155 in 257131, which is

7149    if (sched_verbose >= 2)
7150      {
7151        sel_print ("scheduled insn %d, clock %d\n", INSN_UID (insn),
7152                   haifa_clock + 1);
7153        debug_state (curr_state);
7154      }
7155    gcc_assert (cost < 0);
7156  }
7157
7158  if (targetm.sched.variable_issue)
7159    targetm.sched.variable_issue (sched_dump, sched_verbose, insn, 0);

(In reply to Aldy Hernandez from comment #3)
> I tried again with latest trunk but still can't reproduce.  I even tried on
> a native PPC big endian box running in 32 bit mode (setarch).

% for cpu in 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603
603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5
a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e power3 power4 power5
power5+ power6 power6x power7 power8 power9 powerpc powerpc64 powerpc64le rs64
titan; do powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180128 -mcpu=$cpu -O2
-fmodulo-sched -fselective-scheduling2 -c tt.c || echo $cpu; done
during RTL pass: sched2
tt.c: In function 'ny':
tt.c:13:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7155
 }
 ^
0xc08418 reset_sched_cycles_in_current_ebb
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7155
0xc08418 sel_region_target_finish
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7228
0xc08418 sel_region_finish
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7284
0xc08418 sel_sched_region(int)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7647
0xc08641 run_selective_scheduling()
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7718
0xbdf4bd rest_of_handle_sched2
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sched-rgn.c:3729
0xbdf4bd execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sched-rgn.c:3873
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
zsh: exit 1     powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180128 -mcpu=$cpu -O2
-fmodulo-sche
power7

So apparently the processor-specific scheduling parameters play a role here.

(In reply to Aldy Hernandez from comment #3)
> Reporter also
> filed PR84090, which also can't be reproduced by at least two people.

I wonder what exactly this is supposed to mean. The ICE reported in PR84090 had
indeed gone between r256935 and r257131 and that would be sorted out by me
later this week anyway.

Reply via email to