[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c

2015-01-14 Thread kkojima at gcc dot gnu.org
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

2015-01-14 Thread jan.kratochvil at redhat dot com
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

2015-01-13 Thread rguenth at gcc dot gnu.org
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

2014-12-15 Thread rguenth at gcc dot gnu.org
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

2014-12-15 Thread vmakarov at gcc dot gnu.org
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

2014-12-15 Thread kkojima at gcc dot gnu.org
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!