This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [vta,trunk?] stabilize hashing of SSA names and builtin function DECLs


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]