> On 64-bit sparc, integer regs are 64-bit and float regs are > (basically) 32-bit. So HARD_REGNO_NREGS(float_reg, DFmode) is 2, and > HARD_REGNO_NREGS(integer_reg, DImode) is 1. > > cprop sees the sequence: > > (insn 330 172 230 .. (set (reg:DI %g2) const_int) > (insn 171 330 173 .. (set (reg:DF %f10) (reg:DF %g2))) > (insn 173 171 222 .. (set (reg:DF %f2) (reg:DF %f10))) > (insn 222 173 223 .. (set (MEM:SI ..) (reg:SI %f10))) > (insn 223 222 174 .. (set (MEM:SI ..) (reg:SI %f11))) > > And then it believes that in insn 222 it can replace %f10 with %g2, > but this is not a correct transformation. > > cprop uses hard_regno_nregs[][] to attempt to detect illegal cases > like this one, but such checks will not trigger here because > hard_regno_nregs[][] is '1' for all of the registers being inspected: > > hard_regno_nregs[][] (reg:SI f10) 1 > hard_regno_nregs[][] (reg:DI g2) 1
There seems to be a hole in the checks, as the number of registers is 2 for some of the intermediate steps. > To reproduce build gcc.c-torture/execute/ieee/mzero.c with > "-m64 -mcpu=niagara3 -O2" on sparc. AFAICS there is no such file as gcc.c-torture/execute/ieee/mzero.c. > I'm suspecting that perhaps cprop is ok, and the real issue is that > sparc's definition of CANNOT_CHANGE_MODE_CLASS needs to be adjusted. I'm a little skeptical at this point. -- Eric Botcazou
