This is weird; I cannot reproduce the behaviour even with the exact configure and command lines you specify. I've been using SVN rev. 195717; which revision do you see the problem with?
In the generated test.ii.208r.ira file I get, I see different register uses even before IRA, compared to your version.
Would you mind sending me (offline) a full set of the dump files so I can see where my compile run starts to diverge from yours?

Depending on configure tests of the installed (cross-)assembler, the ICE may not occur. In those cases, I'm now able to reliably reproduce the ICE by using -fno-section-anchors (in addition to the flags given above).

The problem occurs with the following insn:
(insn 539 383 384 46
(set (reg:DI 355 [313]) (const_int 256 [0x100]))
test.ii:128 643 {*movdi_vfp}
(expr_list:REG_EQUIV (const_int 256 [0x100])
(nil)))
Register 355 is recognized as always-equal to the constant 256, and insn 539 is the insn that originally sets up the equivalence. If the register doesn't get a hard reg, what ought to happen is that users of reg 355 get replaced by the constant, and the insn setting the equivalence ought to be deleted. Because the insn will get deleted anyway, it also ought to be skipped for find_reloads.
To achieve that, reg_equiv_constant(355) should hold the constant, and reg_equiv_init(355) should point to the above insn. However, what actually happens in this test case is that reg_equiv_init(355) is NULL. Therefore, the insn is *not* skipped for find_reloads, which then aborts since it tries to push an output reload for an always-constant register, which is not supposed to happen.
Now the register is somewhat special in that it was created by IRA via live range splitting. The original register was reg 313; and this still has reg_equiv_init(313) pointing to the above insn. However, reg_equiv_init(355) is NULL. There is a routine fix_reg_equiv_init in ira.c which appears to be intended to fix the reg_equiv_init settings of new registers created by live range splitting. However, this doesn't seem to have worked in this case ...
Unfortunately I'm not really familiar with the live range splitting code; maybe Vladimir can help with this?