[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148 --- Comment #6 from Vladimir Makarov --- Author: vmakarov Date: Wed Feb 10 18:01:40 2016 New Revision: 233283 URL: https://gcc.gnu.org/viewcvs?rev=233283&root=gcc&view=rev Log: 2016-02-10 Vladimir Makarov PR target/69148 * lra-constraints.c (curr_insn_transform): Find in/out operands for secondary memory moves. Update dups. 2016-02-10 Vladimir Makarov PR target/69468 * gcc.target/s390/pr69148.c: New. Added: trunk/gcc/testsuite/gcc.target/s390/pr69148.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
Andreas Krebbel changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #5 from Andreas Krebbel ---
I think the problem comes with the hard coded operand indexes in
curr_insn_transform when trying to reuse the existing insn for the secondary
memory load.
if (use_sec_mem_p)
{
rtx new_reg, src, dest, rld;
machine_mode sec_mode, rld_mode;
lra_assert (sec_mem_p);
lra_assert (curr_static_id->operand[0].type == OP_OUT
&& curr_static_id->operand[1].type == OP_IN);
dest = *curr_id->operand_loc[0];
src = *curr_id->operand_loc[1];
...
This does not work for parallels consisting of more than one set.
(insn 15 14 24 2 (parallel [
(set (reg:CCZ 33 %cc)
(compare:CCZ (subreg:SI (reg:SF 69 [ D.1498 ]) 0)
(const_int 0 [0])))
(set (reg:SI 60 [ D.1497 ])
(subreg:SI (reg:SF 69 [ D.1498 ]) 0))
]) t.c:13 839 {*tstsi_extimm}
(expr_list:REG_DEAD (reg:SF 69 [ D.1498 ])
(expr_list:REG_UNUSED (reg:CCZ 33 %cc)
(nil
The first set is dead so single_set returns just the second set for
curr_insn_set. Since the operands in the second set are NOT numbered 0 and 1
this code doesn't do the right thing.
Can we just use the "old" code in such a case? So emitting both the spill insns
before and after the original insn instead of trying to reuse the insn? In the
original PR55433 this was supposed to fix an infinite loop in reload. So I'm
not sure if that might bring back that problem then?!
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |5.4
--- Comment #3 from Jakub Jelinek ---
Ah, ok, I can confirm
union U { int r; float f; };
struct A {
double foo (double);
void bar (int);
int a;
U b[64];
};
void
A::bar (int x)
{
U y;
y.f = foo (b[x].f);
a = y.r ? 4 : y.r;
}
ICEs with -O -march=z196 -m64 on the trunk as well.
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
--- Comment #4 from Jakub Jelinek ---
And
union U { int r; float f; };
struct A {
int a;
union U b[64];
};
double foo (double);
void
bar (struct A *z, int x)
{
union U y;
y.f = foo (z->b[x].f);
z->a = y.r ? 4 : y.r;
}
too (to make it C rather than C++).
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 Ever confirmed|0 |1 --- Comment #2 from Andreas Krebbel --- I can confirm this for GCC 5 branch compiling with -march=z196. It does not seem to get triggered with older -march levels. It also does work fine with -mno-lra. On S/390 we need a memory slot when copying 32 bit entities between FPRs and GPRs. So from a first glance it appears to be related to the handling of secondary memory needed in LRA.
[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
This doesn't even compile on the trunk:
pr69148.C:7:17: error: flexible array member ‘adsp21062_device::m_r’ not at end
of ‘class adsp21062_device’
SHARC_REG m_r[];
^
pr69148.C:6:7: note: in the definition of ‘class adsp21062_device’
class adsp21062_device {
^~~~
If I move m_r declaration to the end, then it compiles fine.
