"Pranav Bhandarkar" <[EMAIL PROTECTED]> writes: > > (reg:SF 139) can hold the value (const_double:SF 0) but (subreg:SI > > (reg:SF 139)) should be the value (const_int 0). Perhaps the problem > > is how we handle a REG_EQUAL note when the destination of the set is a > > SUBREG. > > (subreg:SI (reg:SF 139), 0) shouldnt be able to hold the value > (float:SF (reg:SI 138) ? Am I right on this ?
(subreg:SI (reg:SF 139), 0) implies an SImode lvalue. You can't store an SFmode value into an SImode lvalue. You could store (reg:SI 138) there, or you could store (subreg:SI (float:SF (reg:SI 138)) 0) there. > Because the expander > generates the following while storing the return value > (insn 17 18 19 testcase-min.i:8 (set (subreg:SI (reg:SF 139) 0) > (mem/c/i:SI (reg/f:SI 129 virtual-stack-vars) [2 S4 A32])) -1 > (expr_list:REG_LIBCALL_ID (const_int 1 [0x1]) > (insn_list:REG_RETVAL 14 (expr_list:REG_EQUAL (float:SF (reg:SI 138)) > (nil))))) I guess that insn arguably has a mismatch between the mode of the REG_EQUAL node and the mode of the destination of the set. It's a confusing situation. Ian
