On Jun 23, 2010, at 19:40, Ian Lance Taylor wrote:
Basile Starynkevitch <bas...@starynkevitch.net> writes:
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
Tom de Vries <tjvr...@xs4all.nl> writes:
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into bug 31230. I minimized the testcase, did an
analysis, created a naive patch to test my hypothesis, tested the
patch and put it in the bug report. Now I'm looking for feedback.
In the question I asked to this mailing list I tried to abstract
away
From the specific case I analyzed, to get a more conceptual
discussion about the garbage collector, but maybe that was a
mistake,
sorry for the confusion.
My analysis, what I'm trying to get confirmed, is that the the
actual
type_hash_marked_p() in gcc is 'such an if_marked property':
...
static int type_hash_marked_p (const void *p) {
tree type = ((struct type_hash *) p)->type;
return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type);
}
Interesting. My first reaction is that this is an invalid use of
the
garbage collector. I think there is really only one valid function
that can be used as an if_marked function: one which checks
ggc_marked_p on the structure.
A plugin providing its own GC above GGC, like MELT does, also
could use
that feature. So don't remove it, please.
I'm not proposing removing any feature. I'm stating my belief that
using if_marked with a function which does anything other than test
ggc_marked_p will not work. I don't think it works today, and I don't
think we should put effort into making it work.
Ian
Going from your assessment that the current implementation of
type_hash_marked_p() is incorrect, I think that for 4.4, 4.5 and
trunk it's enough just to remove the TYPE_SYMTAB_POINTER from the
clause (-funit-at-a-time is hardcoded and makes sure the types
between functions stay alive). Fixing this by building a separate
garbage collection root as you suggest would only be needed for 4.3
and earlier.
However, my feeling is that the problem does not classify as a
regression, so I suppose we'd only fix it for the trunk anyway. I'll
try to test a patch for the trunk.
Tom
