This is the mail archive of the
mailing list for the GCC project.
Re: [vta,trunk?] stabilize hashing of SSA names and builtin function DECLs
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Alexandre Oliva" <aoliva at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 Oct 2008 21:17:00 +0100
- Subject: Re: [vta,trunk?] stabilize hashing of SSA names and builtin function DECLs
- References: <email@example.com>
2008/10/29 Alexandre Oliva <firstname.lastname@example.org>:
> 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.
/* 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?