gimple-range-cache: Fix ICEs when dumping details [PR111967]

The following testcase ICEs when dumping details.
When m_ssa_ranges vector is created, it is safe_grow_cleared (num_ssa_names),
but when when some new SSA_NAME is added, we strangely grow it to
num_ssa_names + 1 instead and later on the 3 argument dump method
iterates from 1 to m_ssa_ranges.length () - 1 and uses ssa_name (x)
on each; but because set_bb_range grew it one too much, ssa_name
(m_ssa_ranges.length () - 1) might be after the end of the ssanames
vector and ICE.

The fix grows the vector consistently only to num_ssa_names,
doesn't waste time checking m_ssa_ranges[0] because there is no
ssa_names (0), it is always NULL, before using ssa_name (x) checks
if we'll need it at all (we check later if m_ssa_ranges[x] is non-NULL,
so we might check it earlier as well) and also in the last loop
iterates until m_ssa_ranges.length () rather than num_ssa_names, I don't
see a reason for the inconsistency and in theory some SSA_NAME could be
added without set_bb_range called for it and the vector could be shorter
than the ssanames vector.

To actually fix the ICE, either the first hunk or the last 2 hunks
would be enough, but I think it doesn't hurt to change all the spots.

2023-11-13  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/111967
	* gimple-range-cache.cc (block_range_cache::set_bb_range): Grow
	m_ssa_ranges to num_ssa_names rather than num_ssa_names + 1.
	(block_range_cache::dump): Iterate from 1 rather than 0.  Don't use
	ssa_name (x) unless m_ssa_ranges[x] is non-NULL.  Iterate to
	m_ssa_ranges.length () rather than num_ssa_names.

	* gcc.dg/tree-ssa/pr111967.c: New test.

0 files changed, 0 insertions, 0 deletions