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: [ping patch] enhancing gengtype for plugins?

Rafael Espindola wrote:
Bootstrapped on x86_64-linux-gnu (Debian/Sid/AMD64). The extra functionality
has been tested - see
The usual functionality (the GTY handling inside GCC) did not change.

A very big thanks for reading my patch . I was almost depressed nobody took his time to read it.
Ok for trunk?

I like the idea, but I am not familiar with the gc or gentype.
I am beginning to believe that I am more familiar with GGC than a lot of other people.
Do you have a small plugin that uses this? Would you mind adding it to
the testsuite? You might have to edit the .exp to tell it how to run

I don't have any *small* plugin that uses that. I have MELT that uses it, but MELT is definitely not a *small* plugin (and I am not able to make it much smaller).
(To be exact, I need this gengtype patch to be accepted to make MELT a plugin itself).

Besides, having my gengtype patch accepted in the trunk is, in my current perception, the last feature I need in trunk to be able to pluginify MELT (and this matters a lot to me; I understood that MELT would never be used unless it is a plugin, because compiling an entire GCC branch is too big an effort for most people [outside of the GCC community]).

On a more philosophical view:

* the ability to generate extra GGC roots is essential for the use of PLUGIN_REGISTER_GGC_ROOTS (which has already been accepted inside the trunk). To use this PLUGIN_REGISTER_GGC_ROOTS feature, you really need to generate extra GGC roots, and to do that, you need the functionality my gengtype patch provides. The only other (ugly & dirty & shameful) way would be to hack on one's private branch gengtype to generate the gt-plugin.h file, which means hacking gengtype to do what my small patch provides.

* I would suppose that in practice, only significant plugins (this in practice means "big" plugins, requiring more than a person-year to develop them) would want to register extra roots using PLUGIN_REGISTER_GGC_ROOTS.

* I cannot imagine any small plugin, suitable for testsuite integration, which really would require a non-empty table to be registered with PLUGIN_REGISTER_GGC_ROOTS. And most importantly, to really exercise this feature (which is a trivial feature for any one understanding how garbage collectors work!) you'll need to have cc1 do complex enough things so that the GGC is really called inside the plugin.

* Hence, in pratice, I believe that most robust testcases for these features would be much much larger that the small gengtype patch I am proposing. I could try to develop such a testcase if people care about it. I definitely would prefer it to be a pluginified MELT, but by no means I am daring suggest that MELT would go into the testsuite (since MELT is really a big lot of code). But assuming I take a lot of time to make a real testcase for these features, who would review a much bigger patch than the one (on gengtype) we are talking about?
(FWIW, I am very scared each time I am submitting a patch to the trunk; my major concern is that nobody cares).

Please help me by explaining me what should I do to get this small gengtype functionality accepted inside the trunk. I am lost! Should I take a lot of time to develop an ad-hoc plugin which exercise this feature as a test case (but then, the testcase would be much bigger than the gengtype patch I am trying to push, and I believe a big patch has much less chances to be accepted than a small one)?

Having this gengtype patch be accepted in the trunk is very important to me (because it would enable me to pluginify MELT, which is important to me), but I don't know what to do (and I am scared to annoy the few people willing to review it)!! Please tell me what do!! I'll do almost anything honest to have it accepted in the trunk!

And please be kind with me: there are a big lot of cultural & linguistic differences between you and me (in particular, I am not a native English speaker, & I don't live in a north American corporate culture).

The major point of my gengtype patch is that it should be easy to review, since it is simple & short. I do admit it is not very elegant, since it just avoid printing (the non-plugin generated part) in gengtype. But gengtype is running fast enough, and most importantly, is only useful at plugin or trunk build time (the gengtype code is never used in an actual cc1 invocation; what is used is code generated by gengtype!)


email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

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