On 09/07/15 14:24, Michael Matz wrote:
Hi,
On Thu, 9 Jul 2015, Tom de Vries wrote:
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.
Attached patch tries to get multi-step dependencies right, without
using iteration-till-fixed-point.
And for the record, attached patch implements a naive iterative
approach.
What uses do multi-step dependencies have? As in, I think this goes into
the wrong direction, we lived without this since years, so why should
this
situation be handled at all? It's about cache hash tables, so they
shouldn't contain anything that is only pointed to at by entries in those
tables.
If anything we rather should check, that calling gt_ggc_mx on anything
retained in the hash tables doesn't generate newly live objects.
Hi Michael,
I'm trying to get to a defined policy for what is allowed for caches.
Either forbidding or allowing multi-step dependencies, I don't really mind.
Until now, we didn't have a good way of allowing them. I came up with a
runtime efficient but not exhaustive variant, which I posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00711.html.
As contrast and for the record, I posted the exhaustive but not runtime
efficient variant here:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00730.html.
I managed to write a patch series that implements the forbidding of
multi-step dependencies. I'll post this soon.