https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92741
--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> This comes from:
>
> if (!useless_type_conversion_p (TREE_TYPE (rhs), TREE_TYPE (v->value)))
> {
> if (fold_convertible_p (TREE_TYPE (rhs), v->value))
> val = fold_build1 (NOP_EXPR, TREE_TYPE (rhs), v->value);
> else if (TYPE_SIZE (TREE_TYPE (rhs))
> == TYPE_SIZE (TREE_TYPE (v->value)))
> val = fold_build1 (VIEW_CONVERT_EXPR, TREE_TYPE (rhs), v->value);
>
> in ipcp_modif_dom_walker::before_dom_children. fold_convertible_p
> is returning true for the mismatched vector types, which is clearly
> a bug and I have a fix. But does anyone have any thoughts on whether
> the above code is correct?
We do the same for inlining (and IPA-SRA) in force_value_to_type in
tree-inline.c which is where I guess this comes from. There it is
meant to deal with potential parameter type promotion but you are
right that with values passed in aggregates, V_C_Eing always makes
more sense.
> It seems strange to be trusting
> fold_convertible_p with the choice when this kind of type punning
> always acts as a VIEW_CONVERT_EXPR-style reinterpret of the
> memory contents. Earlier we have:
>
> if (!v
> || v->by_ref != by_ref
> || maybe_ne (tree_to_poly_int64 (TYPE_SIZE (TREE_TYPE (v->value))),
> size))
> continue;
>
> which I guess makes it safe in practice.
Yes, I guess it would.
