This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: question about if_marked construct

Basile Starynkevitch <> writes:

> On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
>> Tom de Vries <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]