This is the mail archive of the
mailing list for the GCC project.
Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)
On Tue, Mar 20, 2012 at 12:47 PM, Ludovic Courtès
> Hi Richard,
> Richard Guenther <firstname.lastname@example.org> skribis:
>> 2012/3/19 Ludovic Courtès <email@example.com>:
>>> 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 :
> ?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
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.
>  https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&root=starpu