https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-05-17
Blocks| |63426
Keywords| |ice-on-valid-code
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Breakpoint 6, range_cast (r=..., type=<record_type 0x7ffff73eda80 S0>) at
/home/apinski/src/upstream-gcc/gcc/gcc/range-op.cc:4853
4853 Value_Range tmp (r);
Confirmed.
The code looks like:
```
int g_5, func_1_l_32, func_50___trans_tmp_31;
...
int func_1() { func_50(g_3_4, g_5, func_1_l_32, 8, 3); }
...
struct S0 *func_50(int p_51, struct S0 p_52, struct S1 p_53, int p_54,
int p_55) {
...
}
```
Code in gcc:
if (TREE_CODE (arg) == SSA_NAME
&& param_type
/* Limit the ranger query to integral types as the rest
of this file uses value_range's, which only hold
integers and pointers. */
&& irange::supports_p (TREE_TYPE (arg))
&& get_range_query (cfun)->range_of_expr (vr, arg)
&& !vr.undefined_p ())
{
value_range resvr = vr;
range_cast (resvr, param_type);
if (!resvr.undefined_p () && !resvr.varying_p ())
ipa_set_jfunc_vr (jfunc, &resvr);
else
gcc_assert (!jfunc->m_vr);
}
else
gcc_assert (!jfunc->m_vr);
Maybe there should be an extra check for `irange::supports_p (param_type)` too
to catch the case where param_type type is not supported at all.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
