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: [PATCH 11/11] Make opt_pass and gcc::pipeline be GC-managed

On Sat, Aug 3, 2013 at 2:21 AM, Richard Henderson <> wrote:
> On 08/02/2013 11:53 AM, David Malcolm wrote:
>> FWIW I had a go at avoiding templates by attempting to tell gengtype to
>> write out functions for all GTY((user)) types, regardless of whether it
>> thinks they're referenced, with this:
>> @@ -3697,7 +3697,8 @@ write_types (outf_p output_header, type_p structures, type_p param_structs,
>>    /* At last we emit the functions code.  */
>>    oprintf (output_header, "\n/* functions code */\n");
>>    for (s = structures; s; s = s->next)
>> -    if (s->gc_used == GC_POINTED_TO || s->gc_used == GC_MAYBE_POINTED_TO)
>> +    if (s->gc_used == GC_POINTED_TO || s->gc_used == GC_MAYBE_POINTED_TO
>> +        || s->kind == TYPE_USER_STRUCT)
>>        {
>>         options_p opt;
>> but I ran into various "incomplete structure" errors due to gengtype's
>> lack of a full C/C++ parser.
>> Hence templates seem the sanest option.
> I was actually contemplating going the other direction -- have gengtype
> write out _less_, relying on the templates more.  I hadn't gone very far
> down that road yet...

That was the original idea, btw (well, the original idea was to get rid of
gengtype completely of course).

Btw, I don't like moving the pass pipeline and pass objects into GC space.
It doesn't make much sense as pass execution is quite constrained so
passes should not allocate objects that extend the passes lifetime.


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