Hi!
In this case the problem is that during cselib_process_insn
the cselib hashtab is expanded. Before the htab expansion
cselib_lookup on r1 - 1 gave value 18:18 which contains the right value, but
doesn't have the hash value for r1 - 1 (8169), thus is found only by
accident. Unfortunately after the expansion we don't look at the 18:18
value at all, don't find a value and thus a new value for r1 - 1 is
created (27:8169). Unfortunately the expected MEM value is in 18:18's
addr_list, not in 27:8169, so add_stores doesn't find it (and is create=0
call, thus it returns NULL).
In other places we don't assume that cselib_lookup with create=0 will
always return non-NULL, so we shouldn't do it here either.
For 4.8 I guess we should investigate if we can improve this somehow.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-01-04 Jakub Jelinek <ja...@redhat.com>
PR debug/51746
* var-tracking.c (add_stores): For COND_EXEC allow oval to be NULL.
--- gcc/var-tracking.c.jj 2012-01-01 19:54:46.000000000 +0100
+++ gcc/var-tracking.c 2012-01-04 11:30:44.033223790 +0100
@@ -5519,7 +5519,7 @@ add_stores (rtx loc, const_rtx expr, voi
gcc_assert (oval != v);
gcc_assert (REG_P (oloc) || MEM_P (oloc));
- if (!cselib_preserved_value_p (oval))
+ if (oval && !cselib_preserved_value_p (oval))
{
micro_operation moa;
Jakub
