Although copy_value() in regcprop.c tries to avoid recording cases
where substitutions would be illegal, there are some bad cases it
still can let through.
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
The (set (reg:DI %g2) const_int) is generated by the *movdf_insn_sp64 insn
which in turn triggers a splitter for loading float constants into
integer registers.
The MEM:SI stores are reloads generated by IRA for a pseudo that has
to live across a call. For whatever reason it allocated only a 4-byte
aligned stack location, and I suppose that is why the reload is split
into 2 SImode pieces.
To reproduce build gcc.c-torture/execute/ieee/mzero.c with
"-m64 -mcpu=niagara3 -O2" on sparc.
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.
