http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51746
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-04
10:40:35 UTC ---
Looks latent before to me.
The issue is that when cselib_process_insn for
(insn 56 51 60 4 (cond_exec (eq (reg:CC 24 cc)
(const_int 0 [0]))
(set (mem:QI (plus:SI (reg:SI 1 r1 [orig:169 ivtmp.6 ] [169])
(const_int -1 [0xffffffffffffffff])) [0 MEM[base: 0B,
index: ivtmp.6_13, offset: 4294967295B]+0 S1 A8])
(reg:QI 2 r2 [176]))) pr51746.i:16 3031 {*p *arm_movqi_insn}
(nil))
is called, initially when doing cselib_lookup on the r1 - 1, we get value
18:18,
but still during processing of that insn htab_expand is called on the cselib
hash table, as it reached the 3/4 fullness limit. After this expand we don't
find VALUE 18:18 for r1 - 1 anymore and instead create VALUE 27:8168 (8168 is
the hash value of r1 - 1 at that point). But that means cselib_lookup on
(mem:QI (value 27:8168)) in add_stores fails, because the desired value that
was created earlier on for (mem:QI (r1 - 1)) is in value 18:18's addr_list, not
in 27:8168's addr_list and add_stores calls cselib_lookup with create=0.
It seems most of the places in var-tracking.c that call cselib_lookup with
create=0 allow it to return NULL, but not this spot. So the easiest fix is
just handle the oval == NULL case. And we can think about some improvements if
it would be possible to improve this case somehow. E.g. if cselib_find_slot
in cselib_lookup_1 succeeeds, but returns a value with e->hash != hash, perhaps
we could insert a cselib_val with the desired hash and make it
cselib_add_permanent_equiv to the actual value found? Perhaps not 4.7
material...
