https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124436
Bug ID: 124436
Summary: "cc1: out of memory allocating 18446744065119617032
bytes after a total of 1380352 bytes" with
--param=min-nondebug-insn-uid=1073741824
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: mips64el-unknown-linux-gnuabi64
Compiler output:
$ echo 'void foo(){}' | mips64el-unknown-linux-gnuabi64-gcc
--param=min-nondebug-insn-uid=1073741824 -xc - -wrapper valgrind,-q
==29312== Argument 'size' of function realloc has a fishy (possibly negative)
value: -8589934584
==29312== at 0x485016C: realloc (vg_replace_malloc.c:1804)
==29312== by 0x218BF10: xrealloc (xmalloc.c:181)
==29312== by 0x1CB9536: dfa_insn_code_enlarge(int) (insn-automata.cc:127384)
==29312== by 0x1CB95E4: dfa_insn_code (insn-automata.cc:127397)
==29312== by 0x1CB95E4: state_transition(void*, rtx_def*)
(insn-automata.cc:127417)
==29312== by 0x15E5432: mips_sim_wait_units(mips_sim*, rtx_insn*)
(mips.cc:18855)
==29312== by 0x15FE836: mips_sim_wait_insn (mips.cc:18865)
==29312== by 0x15FE836: mips_seq_time (mips.cc:18962)
==29312== by 0x15FE836: mips_mult_zero_zero_cost(mips_sim*, bool)
(mips.cc:18989)
==29312== by 0x15FEA59: mips_set_fast_mult_zero_zero_p (mips.cc:19008)
==29312== by 0x15FEA59: mips_set_tuning_info() (mips.cc:19035)
==29312== by 0xB75F78: (anonymous
namespace)::pass_expand::execute(function*) (cfgexpand.cc:7083)
==29312== by 0x103D40F: execute_one_pass(opt_pass*) (passes.cc:2656)
==29312== by 0x103DD1F: execute_pass_list_1(opt_pass*) (passes.cc:2769)
==29312== by 0x103DD58: execute_pass_list(function*, opt_pass*)
(passes.cc:2780)
==29312== by 0xBBA5F8: expand (cgraphunit.cc:1874)
==29312== by 0xBBA5F8: cgraph_node::expand() (cgraphunit.cc:1827)
==29312==
cc1: out of memory allocating 18446744065119617032 bytes after a total of 0
bytes
It seems there is an arithmetics overflow somewhere, possibly leading to
out-of-bounds access. I could reproduce this issue only with mipsel and
mips64el.
$ mips64el-unknown-linux-gnuabi64-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-mips64el/bin/mips64el-unknown-linux-gnuabi64-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20260309124537-r16-7957-ge1eb2472c965a1-checking-yes-rtl-df-extra-mips64el/bin/../libexec/gcc/mips64el-unknown-linux-gnuabi64/16.0.1/lto-wrapper
Target: mips64el-unknown-linux-gnuabi64
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--enable-libsanitizer --with-sysroot=/usr/mips64el-unknown-linux-gnuabi64
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=mips64el-unknown-linux-gnuabi64
--with-ld=/usr/bin/mips64el-unknown-linux-gnuabi64-ld
--with-as=/usr/bin/mips64el-unknown-linux-gnuabi64-as --disable-multilib
--with-abi=64 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20260309124537-r16-7957-ge1eb2472c965a1-checking-yes-rtl-df-extra-mips64el
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.1 20260309 (experimental) (GCC)
