diff mbox

Fix arm var-tracking ICE (PR debug/51746)

Message ID orsjjshbrs.fsf@livre.localdomain
State New
Headers show

Commit Message

Alexandre Oliva Jan. 6, 2012, 7:27 p.m. UTC 
On Jan  4, 2012, Jakub Jelinek <jakub@redhat.com> wrote:

> 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).

The problem was a bug in the hash number computation for the reverse
operation, that used the hash number of the original r1's VALUE when it
was in a register, but didn't use it when we computed the hash code of
the expression with a VALUE instead of the REG.

This patch fixes expression hash computation so that it uses the hash
code of a VALUE just as it would for REGs and MEMs, so that we compute
the same hashcode and locate the VALUEs for reverse expressions
correctly.

Regstrapped on x86_64-linux-gnu and i686-linux-gnu, verified to solve
the ARM problem, with and without your patch.

I'm checking it in as obvious.
diff mbox

Patch

Index: gcc/cselib.c
===================================================================
--- gcc/cselib.c.orig	2012-01-06 14:18:38.954548069 -0200
+++ gcc/cselib.c	2012-01-06 14:18:44.952460886 -0200
@@ -1035,6 +1035,10 @@  cselib_hash_rtx (rtx x, int create, enum
 
   switch (code)
     {
+    case VALUE:
+      e = CSELIB_VAL_PTR (x);
+      return e->hash;
+
     case MEM:
     case REG:
       e = cselib_lookup (x, GET_MODE (x), create, memmode);