https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-14 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:80f13430350276a8c932d068c971cc00d5e43b78 commit r14-10771-g80f13430350276a8c932d068c971cc00d5e43b78 Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Oct 1 09:52:20 2024 +0200 range-cache: Fix ranger ICE if number of bbs increases [PR116899] Ranger cache during initialization reserves number of basic block slots in the m_workback vector (in an inefficient way by doing create (0) and safe_grow_cleared (n) and truncate (0) rather than say create (n) or reserve (n) after create). The problem is that some passes split bbs and/or create new basic blocks and so when one is unlucky, the quick_push into that vector can ICE. The following patch replaces those 4 quick_push calls with safe_push. I've also gathered some statistics from compiling 63 gcc sources (picked those that dependent on gimple-range-cache.h just because I had to rebuild them once for the instrumentation), and that showed that in 81% of cases nothing has been pushed into the vector at all (and note, not everything was small, there were even cases with 10000+ basic blocks), another 18.5% of cases had just 1-4 elements in the vector at most, 0.08% had 5-8 and 19 out of 305386 cases had at most 9-11 elements, nothing more. So, IMHO reserving number of basic block in the vector is a waste of compile time memory and with the safe_push calls, the patch just initializes the vector to vNULL. 2024-10-01 Jakub Jelinek <ja...@redhat.com> PR middle-end/116899 * gimple-range-cache.cc (ranger_cache::ranger_cache): Set m_workback to vNULL instead of creating it, growing and then truncating. (ranger_cache::fill_block_cache): Use safe_push rather than quick_push on m_workback. (ranger_cache::range_from_dom): Likewise. * gcc.dg/bitint-111.c: New test. (cherry picked from commit de25f1729d212c11d6e2955130f4eb1d272b5ce7)
