[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #5)
> (In reply to prathamesh3492 from comment #4)
> > Created attachment 42535 [details]
> > Untested fix
> > 
> 
> > Hi,
> > The issue here for propagating value of 'm' from f_c1 to foo() is that the
> > jump function operation is FLOAT_EXPR, and the type of input param 'm' is
> > int, so fold_unary() doesn't do the conversion to real_type.
> 
> Thanks a lot for the quick the analysis.
> 
> > The attached
> > patch fixes that by calling fold_convert if operation is FLOAT_EXPR and
> > converts it to the type of corresponding parameter in callee.
> > Does this look in the right direction ?
> 
> > --- a/gcc/ipa-cp.c	
> > +++ a/gcc/ipa-cp.c	
> > @@ -1233,7 +1234,13 @@ ipa_get_jf_pass_through_result (struct
> > ipa_jump_func *j> func, tree input)
> >    if (!is_gimple_ip_invariant (input))
> >      return NULL_TREE;
> >  
> > -  if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> > +  if (parm_type &&
> > +      ipa_get_jf_pass_through_operation (jfunc) == FLOAT_EXPR)
> > +    {
> > +      res = fold_convert (parm_type, input);
> > +      restype = parm_type;
> > +    }
> > +  else if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> 
> I don't think it is correct to make parm_type a parameter with NULL
> default value and then only handle FLOAT_EXPR safely when it arrives
> through paths that actually provide a non-NULL value.
> 
> So either we should just always return NULL for FLOAT_EXPR operation
> or return NULL_TREE when operation is FLOAT_EXPR and param_tree is
> NULL (or provide the type from all callers but I can see that might be
> a bit painful).
Indeed, I will modify the patch to return NULL_TREE when operation is
FLOAT_EXPR and parm_type is NULL.
> 
> DO I assume correctly that we have the same problem with
> FIX_TRUNC_EXPR too?
I suppose yes, I will add case for FIX_TRUNC_EXPR in the patch. I am not sure
though how to write a C test-case for generating FIX_TRUNC_EXPR ?

Thanks,
Prathamesh