https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91468
Bug ID: 91468
Summary: Suspicious codes in ipa-prop.c and ipa-cp.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Some might be a bug, and some might be redundant.
ipa-prop.c:
In function ipcp_modif_dom_walker::before_dom_children(),
vce = false;
t = rhs;
while (handled_component_p (t))
{
/* V_C_E can do things like convert an array of integers to one
bigger integer and similar things we do not handle below. */
if (TREE_CODE (rhs) == VIEW_CONVERT_EXPR)
{
vce = true;
break;
}
t = TREE_OPERAND (t, 0);
}
if (vce)
continue;
Should "rhs" in "if (TREE_CODE (rhs) == VIEW_CONVERT_EXPR)" be "t"?
In function update_jump_functions_after_inlining(),
if (dst->type == IPA_JF_ANCESTOR)
{
......
if (src->type == IPA_JF_PASS_THROUGH
&& src->value.pass_through.operation == NOP_EXPR)
{
......
}
else if (src->type == IPA_JF_PASS_THROUGH
&& TREE_CODE_CLASS (src->value.pass_through.operation) ==
tcc_unary)
{
dst->value.ancestor.formal_id =
src->value.pass_through.formal_id;
dst->value.ancestor.agg_preserved = false;
}
......
}
If we suppose pass_through operation is "negate_expr" (while it is not a
reasonable operation on pointer type), the code might be incorrect. It's better
to specify expected unary operations here.
In function compute_complex_assign_jump_func(),
case GIMPLE_UNARY_RHS:
if (is_gimple_assign (stmt)
&& gimple_assign_rhs_class (stmt) == GIMPLE_UNARY_RHS
&& ! CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt)))
ipa_set_jf_unary_pass_through (jfunc, index,
gimple_assign_rhs_code (stmt));
The condition "is_gimple_assign (stmt)
&& gimple_assign_rhs_class (stmt) == GIMPLE_UNARY_RHS" seems to
be redundant, might be omit.
ipa-cp.c:
In function merge_agg_lats_step(),
if (**aglat && (**aglat)->offset == offset)
{
if ((**aglat)->size != val_size
|| ((**aglat)->next
&& (**aglat)->next->offset < offset + val_size))
{
set_agg_lats_to_bottom (dest_plats);
return false;
}
gcc_checking_assert (!(**aglat)->next
|| (**aglat)->next->offset >= offset + val_size);
return true;
}
The condition "|| ((**aglat)->next && (**aglat)->next->offset < offset +
val_size))" seems to be always false, because the next item should not be
overlapped with its prev, this is what merge_agg_lats_step() tries to ensure.
