https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
ipa_get_jf_pass_through_result has multiple issues:
static tree
ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input)
{
tree restype, res;
if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
return input;
we may miss a truncation here (and should check for CONVERT_EXPR_CODE_P).
if (!is_gimple_ip_invariant (input))
return NULL_TREE;
if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
== tcc_unary)
res = fold_unary (ipa_get_jf_pass_through_operation (jfunc),
TREE_TYPE (input), input);
the bug here is that the operation is type-changing but we use the
type of the input(!) rather than the type of the output when computing
the result. I suppose the output is the type of the current formal
parameter -- is that available somehow?
else
{
if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
== tcc_comparison)
restype = boolean_type_node;
else
restype = TREE_TYPE (input);
same issue for operations like widen_sum_expr but of course less likely
to hit us here.
res = fold_binary (ipa_get_jf_pass_through_operation (jfunc), restype,
input, ipa_get_jf_pass_through_operand (jfunc));
}
if (res && !is_gimple_ip_invariant (res))
return NULL_TREE;
I think the immediate thing to do is make the list of handled expression
codes explicit - thus change the tree-code-class checks to
switch (code)
{
case handled-unary:
fold_unary...
case handled-comparison:
...
etc.
or somehow properly get the jf "target" type.
