Hi, On Mon, 6 Jul 2015, Richard Biener wrote:
> >> By doing so, we make the behaviour of gt_cleare_cache independent of the > >> order in which the entries are visited, turning: > >> - hard-to-trigger bugs which trigger for one visiting order but not for > >> another, into > >> - more easily triggered bugs which trigger for any visiting order. > >> > >> Any comments? > > > > I think it is only half-way correct in your proposed change. You only > > fix the issue for hashes of the same kind. To truly fix the issue you'd > > have to change generated code for gt_clear_caches () and provide > > a clearing-only implementation (or pass a operation mode bool to > > the core worker in hash-table.h). > > Hmm, and don't we rather want to first mark and _then_ clear? Because > if entry B in the hash is live and would keep A live then A _is_ kept in > the end but you'll remove it from the hash, possibly no longer using a > still live copy. I don't think such use has ever worked with the caching hash tables. Even the old (before c++) scheme didn't iterate, i.e. if a cache-hash entry A became life from outside, but it itself kept an entry B live in the hash table (with no other references to B) then this never worked (or only by luck), because the slot was always cleared if !ggc_marked_p, so if B was visited before A it was removed from the hash-table (and in particular B's gt_ggc_mx routine was never called, so whatever B needed wasn't even marked). Given this I think the call to gt_ggc_mx is superfluous because it wouldn't work relyably for multi-step dependencies anyway. Hence a situation that works with that call in place, and breaking without it is actually a bug waiting to be uncovered. Ciao, Michael.