http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, the ICE hints at iterative_hash_expr and operand_equal_p being out-of-sync
after the change. Yep:
/* The type of the second operand is relevant, except for
its top-level qualifiers. */
tree type = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (t, 1)));
val = iterative_hash_object (TYPE_HASH (type), val);
it's not required for correctness to hash this type. See also the comment
in more generic code
/* Don't hash the type, that can lead to having nodes which
compare equal according to operand_equal_p, but which
have different hash codes. */
so this seems to be a recurring issue.
There shouldn't be many collisions if just hashing the offset constant,
so simply removing the MEM_REF special casing should work (TARGET_MEM_REF
isn't special-cased either).
So the above was without reproducing it yet (i586 bootstrap still ongoing).
Index: gcc/tree.c
===================================================================
--- gcc/tree.c (revision 202862)
+++ gcc/tree.c (working copy)
@@ -7298,21 +7280,6 @@ iterative_hash_expr (const_tree t, hashv
}
return val;
}
- case MEM_REF:
- {
- /* The type of the second operand is relevant, except for
- its top-level qualifiers. */
- tree type = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (t, 1)));
-
- val = iterative_hash_object (TYPE_HASH (type), val);
-
- /* We could use the standard hash computation from this point
- on. */
- val = iterative_hash_object (code, val);
- val = iterative_hash_expr (TREE_OPERAND (t, 1), val);
- val = iterative_hash_expr (TREE_OPERAND (t, 0), val);
- return val;
- }
case FUNCTION_DECL:
/* When referring to a built-in FUNCTION_DECL, use the __builtin__ form.
Otherwise nodes that compare equal according to operand_equal_p might
