https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so that's guarded with gcse_or_cprop_is_too_expensive which doesn't trigger
but I see it allocating
alloc_cprop_mem (last_basic_block_for_fn (cfun),
set_hash_table.n_elems);
which does 4 times sbitmap_vector_alloc (n_blocks, n_sets) which consumes
n_blocks * n_sets / 2 bytes of memory. gcse_or_cprop_is_too_expensive
uses n_basic_blocks_for_fn but stores the result in an int which quite
likely overflows here, defeating the limitation (eh). Will fix / test.
