Noticed ICE on pkg-config-0.29.2 when was building with gcc from master. Minimal example: //$ cat bug.c.c int g_variant_type_info_basic_table[1]; int g_variant_type_info_check__g_boolean_var_, g_variant_type_info_get_index; int *g_variant_type_info_get_info; int g_assertion_message_expr(); void g_variant_type_info_check(int *info) { int index = info - g_variant_type_info_basic_table; if (index) g_variant_type_info_check__g_boolean_var_ = 1; g_assertion_message_expr(); } void g_variant_type_info_get() { g_variant_type_info_get_info = g_variant_type_info_basic_table + g_variant_type_info_get_index; g_variant_type_info_check(g_variant_type_info_get_info); } Crash: $ gcc -c bug.c.c -o bug.o -O2 during IPA pass: inline bug.c.c:15:1: internal compiler error: Segmentation fault 15 | } | ^ 0x1afc249 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1], diagnostic_t) 0x1afd0b9 internal_error(char const*, ...) 0xc9239f crash_signal(int) 0xf997f4 canonize(long*, unsigned int, unsigned int) 0xbe16b4 range_operator::wi_fold_in_parts(irange&, tree_node*, generic_wide_int<wide_int_storage> const&, generic_wide_int<wide_int_storage> const&, generic_wide_int<wide_int_storage> const&, generic_wide_int<wide_int_storage> const&) const 0xbe1fb4 range_operator::fold_range(irange&, tree_node*, irange const&, irange const&, relation_trio) const 0xa1ea8a evaluate_conditions_for_known_args(cgraph_node*, bool, ipa_auto_call_arg_values*, unsigned int*, unsigned int*) 0xa236ae evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*, unsigned int*, ipa_auto_call_arg_values*, bool) 0xa37972 do_estimate_edge_size(cgraph_edge*) [clone .part.63] 0xa391fa do_estimate_growth_1(cgraph_node*, void*) 0xa39719 estimate_growth(cgraph_node*) 0x19d3931 inline_small_functions() 0x19d47a2 (anonymous namespace)::pass_ipa_inline::execute(function*) gcc is built from r14-283-g95d4c0d2e6318a: $ gcc -v Using built-in specs. COLLECT_GCC=/<<NIX>>/xgcc-14.0.0/bin/gcc COLLECT_LTO_WRAPPER=/<<NIX>>/xgcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 99999999 (experimental) (GCC)
points to ranger changes, confirmed.
Started with r14-249-g3c9372dfee0bb8.
Got a slightly nicer backtrace with debugging symbols: (gdb) bt #0 0x0000000000f70d7b in canonize (val=0x7fffffff9120, len=len@entry=0, precision=precision@entry=576) at ../../source/gcc/wide-int.cc:96 #1 0x0000000000f71699 in wi::force_to_size (val=val@entry=0x7fffffff9120, xval=xval@entry=0x7fffffffa320, xlen=<optimized out>, xprecision=<optimized out>, precision=precision@entry=576, sgn=<optimized out>) at ../../source/gcc/wide-int.cc:400 #2 0x0000000000bd6c3d in fixed_wide_int_storage<576>::from (sgn=<optimized out>, x=...) at ../../source/gcc/wide-int.h:1292 Looks like canonize() below has `val` of zero length: (gdb) print len $1 = 0 (gdb) print val $2 = (long *) 0x7fffffff9120 static unsigned int canonize (HOST_WIDE_INT *val, unsigned int len, unsigned int precision) { unsigned int blocks_needed = BLOCKS_NEEDED (precision); HOST_WIDE_INT top; int i; if (len > blocks_needed) len = blocks_needed; if (len == 1) return len; top = val[len - 1]; ...
dup *** This bug has been marked as a duplicate of bug 109639 ***