https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |jamborm at gcc dot gnu.org
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we get
#12 0x000000000322f21c in ipa_vr_operation_and_type_effects (dst_vr=...,
src_vr=..., operation=ABSU_EXPR,
dst_type=<integer_type 0x7ffff6e1c7e0 long unsigned int>,
src_type=<integer_type 0x7ffff6e1c498 short int>)
at /space/rguenther/src/gcc/gcc/ipa-cp.cc:1692
1692 && handler.fold_range (dst_vr, dst_type, src_vr, varying)
(gdb) l
1687
1688 value_range varying (dst_type);
1689 varying.set_varying (dst_type);
1690
1691 return (handler.operand_check_p (dst_type, src_type, dst_type)
1692 && handler.fold_range (dst_vr, dst_type, src_vr, varying)
1693 && !dst_vr.varying_p ()
1694 && !dst_vr.undefined_p ());
1695 }
1696
(gdb) p dst_type
$1 = <integer_type 0x7ffff6e1c7e0 long unsigned int>
(gdb) p handler
$2 = {m_operator = 0x49ff0a0 <op_absu>}
(gdb) p src_type
$3 = <integer_type 0x7ffff6e1c498 short int>
which means dst_type (or src_type) is off.
We get here from propagate_vr_across_jump_function where for
IPA_JF_PASS_THROUGH
we do no "verification" of operand_type vs. param_type - we seem to trust
that there's a good enough match (or that for NOP_EXPR pass through op
a conversion is possible).
I guess we need a "white-list" for supported operations (only unary are
allowed?) with more specialized handling. I'm not sure we'd want to
insert conversions to satisfy mismatches but rather want to fall back to
VARYING in thise cases.
