https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Andrew Macleod from comment #6) > (In reply to Jakub Jelinek from comment #5) > > Even if create (n) didn't work (which would be good to debug), the > > x.safe_grow_cleared (n); x.truncate (0); can be just done more efficiently > > with x.reserve (n); > > > > Anyway, the more important question is if range-cache can work even if the > > number of basic blocks grows in the middle and whether say just using > > safe_push instead of quick_push would do the trick. > > It works fine with growing CFG. > OK, let me give you a more measured answer instead of yes. :-P the m_workback vector is used for a Walk up the CFG to mark blocks which need to be revisited because the incoming edge changes a specific SSA_NAMES range. These mostly become range-on-entry blocks that need updating, and only those block get put into the stack. As a result, even a walk from the bottom of the CFG to the top should require far less than the full number of blocks. As a result, the cache does use a quick_push. I suppose it is possible that one could add so many basic blocks that this situation could exceed the original size of the vector, however unlikely. The completely safe approach would be to change ranger_cache::fill_block_cache () to either a) assert there is space before calling quick_push or b) change it to a safe_push
