[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Roman Zhuykov changed: What|Removed |Added CC||zhroma at ispras dot ru --- Comment #12 from Roman Zhuykov --- Not sure if I have to reopen it, but fix wasn’t correct. In this example we don’t have -fmodulo-sched-allow-regmoves enabled and we should not create any register moves at all. More discussion and proper fix: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00632.html
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Tue Jan 9 08:03:45 2018 New Revision: 256368 URL: https://gcc.gnu.org/viewcvs?rev=256368=gcc=rev Log: PR target/83507 * modulo-sched.c (schedule_reg_moves): Punt if we'd need to move hard registers. Formatting fixes. * gcc.dg/sms-13.c: New test. Added: trunk/gcc/testsuite/gcc.dg/sms-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/modulo-sched.c trunk/gcc/testsuite/ChangeLog
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Created attachment 43063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43063=edit gcc8-pr83507.patch Untested fix.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 --- Comment #8 from Segher Boessenkool --- Ah yes, I can reproduce it with all those options and -m32. I could swear to have tried exactly that yesterday; pilot error I guess. CA is not just a hard register, but a fixed register, btw.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 Ever confirmed|0 |1 --- Comment #7 from Jakub Jelinek --- BTW, I can reproduce it even with latest trunk: ./cc1.256283 -quiet -O2 -fmodulo-sched -fno-tree-ter -fno-tree-coalesce-vars -mcpu=476 pr83507.c -nostdinc -m32
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added CC||zaks at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- As SMS pass is before reload, another option would be punt on sets to hard registers. But I really know next to nothing about SMS. Is modulo-sched.c maintained at all? I've seen lately only changes to it being changes where something is changed in the whole compiler including modulo-sched.c.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507
--- Comment #5 from Jakub Jelinek ---
Likely just latent before. The ICE is because modulo-sched.c in
for (i_reg_move = 0; i_reg_move < nreg_moves; i_reg_move++)
{
ps_reg_move_info *move = ps_reg_move (ps, first_move + i_reg_move);
move->def = i_reg_move > 0 ? first_move + i_reg_move - 1 : i;
move->uses = sbitmap_alloc (first_move + nreg_moves);
move->old_reg = old_reg;
move->new_reg = gen_reg_rtx (GET_MODE (prev_reg));
move->num_consecutive_stages = distances[0] && distances[1] ? 2 : 1;
move->insn = gen_move_insn (move->new_reg, copy_rtx (prev_reg));
bitmap_clear (move->uses);
prev_reg = move->new_reg;
}
creates a move instruction from the ca register but rs6000 doesn't support such
a move, and apparently nothing attempts to recog that instruction and bail if
it is non-existent (or if gen_move_insn emits more than one instruction).
I think e.g. insn_latency can be only called on successfully recognized
instructions...
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Started with r253530. Bisecting when it went away.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 --- Comment #3 from Arseny Solokha --- I've managed to generate a couple of additional testcases for this PR in December. Next week I'll check whether this ICE is still there w/ my setup.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Segher Boessenkool changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #2 from Segher Boessenkool --- It uses w4 uninitialised, so it is invalid code, too.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 --- Comment #1 from Segher Boessenkool --- I cannot reproduce this on either powerpc-linux or powerpc64-linux.
