https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124436
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:b6b44e0676aeb0812f0e386af4c4f0c549b08822 commit r16-8011-gb6b44e0676aeb0812f0e386af4c4f0c549b08822 Author: Jakub Jelinek <[email protected]> Date: Wed Mar 11 17:28:58 2026 +0100 genautomata: Support INSN_UIDs up to INT_MAX-1 [PR124436] With --param=min-nondebug-insn-uid= parameter one can force really large INSN_UIDs even in moderately large functions. Obviously the compiler will break badly if INSN_UID (which is host int) wraps around, but in dfa_insn_code_enlarge it actually breaks already when INSN_UID reaches INT_MAX / 2 + 1, because it tries to resize vector to twice the max INSN_UID and overflows (UB on the compiler side and then trying to allocate 0xfffffffe00000001-ish bytes). The following patch fixes it by making sure not to overflow and cap the allocation size at INT_MAX (that means even maximum INSN_UID INT_MAX will not work properly, but just reaching that is highly undesirable anyway). Alternatively dfa_insn_codes_length could be e.g. HOST_WIDE_INT and we could just use HOST_WIDE_INT_C (2) * uid, but then we'd allocate parts of vector for something that we really won't use anyway. Of course, it is really bad idea to use --param=min-nondebug-insn-uid=1073741824 or even huge numbers several times smaller than that, because the compiler often allocates arrays sized by maximum INSN_UID, so e.g. compiling empty function on cross to mips64-linux with that argument needed around 38GiB of RAM. 2026-03-11 Jakub Jelinek <[email protected]> PR target/124436 * genautomata.cc (output_dfa_insn_code_func): Use MIN (INT_MAX, 2U * uid) instead of 2 * uid in dfa_insn_code_enlarge.
