This is the mail archive of the gcc@gcc.gnu.org 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: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)


On Tue, Mar 20, 2012 at 12:47 PM, Ludovic Courtès
<ludovic.courtes@inria.fr> wrote:
> Hi Richard,
>
> Richard Guenther <richard.guenther@gmail.com> skribis:
>
>> 2012/3/19 Ludovic Courtès <ludovic.courtes@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


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