On Mon, Jul 6, 2015 at 3:25 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Mon, Jul 6, 2015 at 10:57 AM, Tom de Vries <tom_devr...@mentor.com> wrote: >> Hi, >> >> Using attached untested patch, I managed to minimize a test-case failure for >> PR 66714. >> >> The patch introduces two-phase marking in gt_cleare_cache: >> - first phase, it loops over all the hash table entries and removes >> those which are dead >> - second phase, it runs over all the live hash table entries and marks >> live items that are reachable from those live entries >> >> 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. Richard. > Thanks, > Richard. > >> Thanks, >> - Tom