https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90450
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so it's not operand_equal_p of d[f.1_1] and d[0] returning true but
the comparison involving the ao_ref pieces. And indeed the variable-offset
one is fenced off by
&& (mem_base = get_addr_base_and_unit_offset (aor.ref, &mem_off)))
but using max_size == -1 as tie-breaker doesn't work for the entities in
the hash-table (we never compare!) because we only use max_size == -1
on the on-stack ref we use for the find_slot_with_hash call but actually
insert the original value:
...
else
{
hash = iterative_hash_expr (aor.ref, 0);
aor.max_size = -1;
}
slot = memory_accesses.refs->find_slot_with_hash (&aor, hash, INSERT);
aor.max_size = saved_maxsize;
so the checking code is "flawed"... (I thought we didn't want to lose
the extra disambiguation opportunity from having known max_size).
So - not really a bug.
Could be worked around by extra runtime overhead checking everything
we check before the decision on the hashing scheme also in the equality
routine. Or finding some spare bit in the non-loop-IM private ao_ref
stucture. Or constructing a full im_mem_ref on the stack even if
hash lookup only really needs the ao_ref and put this extra bit there.
Bah :/
Guard the checking on entry type == comparable type?
