Re: GCC 4.7.0RC: Mangled names in cc1

[Richard Guenther <richard dot guenther at gmail dot com>]

2012/3/16 Ludovic CourtÃs <ludovic.courtes@inria.fr>:
> Hi,
>
> Richard Guenther <richard.guenther@gmail.com> skribis:
>
>> 2012/3/16 Ludovic CourtÃs <ludovic.courtes@inria.fr>:
>>> Hi,
>>>
>>> After writing an Autoconf macro that determines whether to build
>>> plug-ins with gcc or g++ [0], I realized that nested functions, which my
>>> plug-in uses extensively, are not supported in C++.
>>>
>>> Any suggestions on how to address this?
>>
>> Don't use nested functions ;) ÂGCC is supposed to be buildable with an ISO C99
>> compiler which does not support nested functions either.
>
> Right, but the nice thing with GCC plug-ins is they can be implemented
> using all GNU extensions.
>
> Nested functions can serve as the basis for some form of functional
> programming, which some of the APIs lend themselves to very well.
> For instance, the plug-in at [0] contains things like:
>
> Â Âtree task = task_implementation_task (fn);
>
> Â Âtree build_parameter (const_tree lst)
> Â Â{
> Â Â Âtree param, type;
>
> Â Â Âtype = TREE_VALUE (lst);
> Â Â Âparam = build_decl (DECL_SOURCE_LOCATION (task), PARM_DECL,
> Â Â Â Â Â Â Â Â Â Â Â Â Âcreate_tmp_var_name ("parameter"),
> Â Â Â Â Â Â Â Â Â Â Â Â Âtype);
> Â Â ÂDECL_ARG_TYPE (param) = type;
> Â Â ÂDECL_CONTEXT (param) = task; Â/* â closed over variable */
>
> Â Â Âreturn param;
> Â Â}
>
> Â ÂDECL_ARGUMENTS (task) =
> Â Â Âmap (build_parameter,
> Â Â Â Â Â list_remove (void_type_p,
> Â Â Â Â Â Â Â Â Â Â Â ÂTYPE_ARG_TYPES (TREE_TYPE (task))));
>
> What if this snippet were to be written in ANSI C99? ÂThe whole âmapâ
> paradigm couldnât be used, because thereâd be no way to close over a
> local variable.
>
> What about writing it in C++? ÂFunction objects could be passed around
> to achieve a similar result, at the expense of conciseness and
> interoperability with C.
>
> This is an unfortunate collateral damage, IMO.

Well, if you invent new paradigms in your plugin that are not used by GCC
itself but use GCC internals (which all plugins have to do ...) then I know
where the problem lies ;)  I suppose you would be better served by
some of the more high-level plugin packages that let you write GCC plugins
in python or lisp?

Or wait until GCC has fully transitioned to C++ (at least I expect we won't
ever relax the rule that GCC can be built with a C++ compiler) and use
C++0x lambdas.

Richard.

> Thanks,
> Ludoâ.
>
> [0] https://gforge.inria.fr/scm/viewvc.php/trunk/gcc-plugin/src/starpu.c?view=markup&root=starpu