This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ICE on valid code, cse related
"Pranav Bhandarkar" <pranav.bhandarkar@gmail.com> 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