https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
--- Comment #14 from David Malcolm <dmalcolm at gcc dot gnu.org> --- (In reply to David Malcolm from comment #7) > (In reply to Andrew Pinski from comment #6) > > What I mean is if you ever traversing a hashtable, the hash should not use > > the value of a pointer because it could change between runs. > > Thanks. > > Unfortunately I'm doing that in quite a few places in the new > implementation, I think. > > The new implementation folds instances of symbolic values and regions into > unique instances, and then uses pointer equality on them (which is good), > and also pointer hashing (which is likely bad, and likely leading to > changeable results). > > I suspect what I need to do is to come up with a deterministic hash for each > of these objects that doesn't rely on pointer values, and to use that value > instead, rather than their addresses. Given the uniqueness of > values/regions per analysis run, I think I'll add a globally unique ID per > value/region and base the hash off of that. > > There are a few places I'm hashing based on trees, for constants and types. > Is there a good way to hash those? (avoiding pointer values) In the end I went with a different approach, sorting the objects into a deterministic order whenever dealing with the results of an iteration over an hash_map or hash_set. So the hash value still depends on the pointer value (and thus can change from run to run), but the result of the iteration does not. See e.g. r11-4434.
