On Tue, 31 May 2011 23:52:11 +0200 Richard Guenther <richard.guent...@gmail.com> wrote: [...] > I don't see a strong need for cross-language plugins with > frontend function access - "meta plugins" such as MELT > may be an exception, but they have to deal with that > in a similar way we deal with frontends - have MELT++, MELTC, > MELTFortran, etc.
Yes, but I really want MELT to remain usable with only the same -fplugin=melt argument in all cases: with or without -flto, for C or C++ or Fortran etc... The naive user wants the same option in all situations (languages, with or without -flto; with some extra -fplugin-arg-melt-... defining the work he want MELT to do). My propositions of adding an invoking_program in struct plugin_gcc_version in http://gcc.gnu.org/ml/gcc/2011-05/msg00324.html and of having -fplugin=name handled differently as -fplugin=`gcc -print-file-name=plugin`/cc1/name.so for cc1 and as -fplugin=`gcc -print-file-name=plugin`/lto1/name.so for lto1 in http://gcc.gnu.org/ml/gcc/2011-05/msg00331.html were both a small step solution to that requirement. You said no to both!! > > Iff we want to make plugins not randomly fail with -flto (which I > think we _do_ want) then it is the plugin loader machines job > to check for compatibility and either ignore (in case of lto1 maybe) > or reject (in other cases) the plugin. So, I don't think a single MELT > plugin that works with all frontend and at the same time has access > to all frontend functions can work. If it could then we would have > not 5 different frontend executables but a single one. I'm ok with having different melt*.so for various situations, as long as the naive user only gives the same -fplugin=melt argument. But I still don't understand concretely what you mean, in other words what kind of solution to you want. Do you think (as I do) that it is bad for any short plugin option like -fplugin=name (i.e. the case when we don't give a full path ending with .so) be running well when invoked as gcc -fplugin=name -O2 foo.c bar.c -o prog and be failing when invoked as gcc -fplugin=name -flto -O2 foo.c bar.c -o prog with a message the naive user don't even understand? What solution do you propose to that issue? I suggested some, but you (Richard) said no to all of them, instead vaguely suggesting more language hooks. But I don't concretely understand what sort of patch you want ... Are you thinking of replacing every occurrence of pragma_lex with e.g. some new field in struct lang_hooks_for_decls inside gcc/langhooks.h ? Or what precisely? You also told us >> Instead we need to expose a defined set of functions and structures, >> and we can easily provide them through indirect dispatch (which opens >> the possibility for a stable API even when the internal API changes - to >> some extent at least). I agree in principle, but who will define and how will be defined that mythical stable API? In my view, you are talking of the mythical ModularGCC project, which should be a mega-patch, and I never saw it on gcc-patches@ so far. What is practically the stable API you are dreaming of? What are the set of C names inside it? As you see, I (& Pierre) have difficulties to even suggest small improvements (since Richard Guenther always say no) so I don't understand at all how *in practice* the stable API will appear. So far, I never saw any patch be accepted in the trunk on that direction. And I believe that any clean-up, or API stabilization, or modularization, patch, is necessarily a big patch: imagine for instance remove just one of the dozens -or hundreds- of important global variables, and making more of an explicit state (perhaps passed by a parameter). Such a patch is necessarily very big, and you cannot make it small by cutting it into pieces (the partial patches won't even compile in isolation). My intuition, is that sadly the stable API (or the Modularization of GCC) cannot appear unless it is defined to be the only goal of trunk patches during a quite a long time (this is why I spoke of a long stage 0 period, probably of several months). And I don't see that happening. The trunk during stage 1 has -as always, and it is good- more and more new features, but few major cleanup. I even dared make the explanation that it cannot happen because the organizations paying us don't want it: that should mean paying us for several months at least working entirely on the stabilization of the API (that is, on modularization). And this is not compatible with each organization's goal. Stabilisatiion of the API and modularization are great goals, but they won't happen soon. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
