[vta,trunk?] stabilize hashing of SSA names and builtin function DECLs
Richard Guenther
richard.guenther@gmail.com
Wed Oct 29 21:16:00 GMT 2008
2008/10/29 Alexandre Oliva <aoliva@redhat.com>:
> I ran into this debugging an -fcompare-debug failure that turned out
> to be a heisenbug. The box had virtual address space randomization
> turned on, and that was what made it a heisenbug.
>
> I don't recall which pass it was that would vary the traverse order in
> a hash table because of varying hash numbers, computed out of
> randomized pointers, but this is not important. (My faulty memory
> tells me it was SCCVN, but I don't see any htab_traverse in there).
>
> Pointers don't belong in hashes that could affect traversal order in a
> way that might change the generated code. We don't want the compiler
> issuing different code just because we recompile. This could even
> break bootstrap!
>
> Turns out it's quite simple to just not use pointers in generic hashes
> at all, and use UIDs instead. This is what this patch does, fixing
> that heisenbug for good.
>
> Here's the patch that I'm checking in. It's the last one I have for
> this series. The branch builds just fine again on x86_64. There are
> still some Ada regressions on i686, and a few compare-debug failures
> here and there that I'm looking into.
case SSA_NAME:
/* we can just compare by pointer. */
- return iterative_hash_pointer (t, val);
+ val = iterative_hash_host_wide_int (DECL_UID (SSA_NAME_VAR (t)), val);
+ val = iterative_hash_host_wide_int (SSA_NAME_VERSION (t), val);
+ return val;
why both? I would say using SSA_NAME_VERSION should be enough?
Richard.
More information about the Gcc-patches
mailing list