On Tue, Mar 20, 2012 at 12:47 PM, Ludovic Courtès <ludovic.cour...@inria.fr> wrote: > Hi Richard, > > Richard Guenther <richard.guent...@gmail.com> skribis: > >> 2012/3/19 Ludovic Courtès <ludovic.cour...@inria.fr>: > > [...] > >>> In the example of name mangling, I’d just have wrapped in ‘extern "C"’ >>> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in. The >>> rationale is that it simplifies plug-in maintenance, while not impeding >>> development work in 4.7. >> >> Well, that's _all_ headers. Basically. > > Well, these headers get installed, and they get installed to be actually > used, don’t they? :-) > >> And exactly the problem. There will be never even API compatibility >> between major releases of GCC with the current plugin "API". > > My experience is more encouraging: between 4.5 and 4.6, I was only hit > by a couple of tree.h declarations found in one and not the other. > > When switching to 4.7, the main problem was mangled names, and all the > problems that making my code compilable with g++ entails. Other issues > were the removal of the ‘built_in_decls’ array, and the new > ‘affects_type_identity’ field of ‘attribute_spec’. > > All this is summarized in the Autoconf macro I use [0]: > > dnl build_call_expr_loc_array -- not in GCC 4.5.x; appears in 4.6 > dnl build_call_expr_loc_vec -- likewise > dnl build_array_ref -- present but undeclared in 4.6.1 > dnl build_zero_cst -- not in GCC 4.5.x; appears in 4.6 > dnl builtin_decl_explicit -- new in 4.7, replaces `built_in_decls' > dnl .affects_type_identity -- new field in 4.7 > > Then again, my plug-in is relatively small, and uses a small part of GCC. > Plug-ins with a larger API footprint may have more problems, of course.
I think it would be nice if you guys (plug-in makers) document what part of the (non-)API you are using currently. Document it on the GCC wiki for example. This way providing an initial guess for a real C plugin API would be easier (and we'd get testing coverage). I would even allow such API be backported to the release branch(es) (given volunteers to backport it). We need to get started at some point - otherwise it will be just repeating discussions. If you have a copyright assignment on file (yeah, I guess even a set of functions that just wrap existing gimple needs that) you might even start at implementing such interface. It might turn out as a convenient library for plugin developers first. Thanks, Richard. > Thanks, > Ludo’. > > [0] > https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&root=starpu
