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: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

On Tue, Mar 20, 2012 at 12:47 PM, Ludovic Courtès
<> wrote:
> Hi Richard,
> Richard Guenther <> skribis:
>> 2012/3/19 Ludovic Courtès <>:
> [...]
>>> In the example of name mangling, I’d just have wrapped in ‘extern "C"’
>>> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/ ?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

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,
> Ludo’.
> [0]

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