https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is on
_gfortran_spread_char_scalar (&atmp.0, _1, &a, &C.4290, &C.4292, _1);
and ipa_compute_jump_functions_for_edge on the _1 arg, which is
<ssa_name 0x7fffea134ab0
type <integer_type 0x7fffea146738 integer(kind=8) public DI
size <integer_cst 0x7fffea12cc48 constant 64>
unit-size <integer_cst 0x7fffea12cc60 constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set 6 canonical-type
0x7fffea146738 precision:64 min <integer_cst 0x7fffea12ced0
-9223372036854775808> max <integer_cst 0x7fffea12cee8 9223372036854775807>
pointer_to_this <pointer_type 0x7fffea17c738> reference_to_this
<reference_type 0x7fffe9f02498>>
visited
def_stmt _1 = MAX_EXPR <_20, 0>;
version:1
ptr-info 0x7fffe9f186e0>
but somehow
tree param_type = ipa_get_callee_param_type (cs, n);
returns VOID_TYPE. So, either it is a bug that parm_type can be some
completely unrelated type to the argument's type, or if it has some special
meaning,
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 ())
should also check that irange::supports_p (param_type) or something similar.
The exact ICE is trying to compute wide_int -1 with precision 0.
