[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300 --- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org --- I think this has been addressed with r218760 by Makarov. Can we close this as resolved?
[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com --- libgcc2.i from Comment 0 builds for me now, thanks.
[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra CC||vmakarov at gcc dot gnu.org Component|target |rtl-optimization Target Milestone|--- |5.0 Summary|s390x, ICE, unable to |[5 Regression] s390x, ICE, |generate reloads, in|unable to generate reloads, |curr_insn_transform, at |in curr_insn_transform, at |lra-constraints.c |lra-constraints.c
[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300 --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #1) I get the same ICE on my local sh-lra branch after r218688. I've looked at what is going on the test case in c#0 with the cross s390 compiler. It seems that the change at r218688 + if (GET_MODE (*curr_id-operand_loc[nop]) != VOIDmode +! hard_reg_set_empty_p (this_alternative_set) +! HARD_REGNO_MODE_OK (ira_class_hard_regs +[this_alternative][0], +GET_MODE (*curr_id-operand_loc[nop]))) doesn't work as intended for some targets. These lines are to check whether a requested mode value can be held by the registers in this_alternative class or not. In the problematic case, gdb shows that GET_MODE (*curr_id-operand_loc[nop]) is DImode and this_alternative is GENERAL_REGS. ira_class_hard_regs[this_alternative] is {1, 2, 3, 4, 5, 0, 11, 10, 9, 8, 7, 6, 0 repeats 26 times} which is a set of regno for GENERAL_REGS in the preferred allocation order. Then ira_class_hard_regs[this_alternative][0] is 1 and HARD_REGNO_MODE_OK (1, DImode) is false. I guess that s390 uses a register pair for DImode in this case and 1 is bad as the starting regno for DImode. Is it right? SH uses the similar allocation order of which the first regno isn't match to the register pair. Thanks for reporting. I've just committed a patch focusing on the same problem. Could you check that the patch solves the problem.
[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300 --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Vladimir Makarov from comment #2) Thanks for reporting. I've just committed a patch focusing on the same problem. Could you check that the patch solves the problem. It fixes the ICE for the given test case on s390 and the similar ICEs on my local sh-lra branch. Thanks!