https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(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).
DO I assume correctly that we have the same problem with
FIX_TRUNC_EXPR too?
