GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès-4]

Hi,

In a build of GCC 4.7.0-RC-20120302 with --enable-languages=c,c++ [0],
I’m seeing C++-mangled name for common functions, like:

  $ objdump -T cc1 | grep build1_stat_loc
  0000000000640a00 g    DF .text  000000000000007a  Base        _Z20fold_build1_stat_locj9tree_codeP9tree_nodeS1_

Indeed, ‘tree.c’, for instance, eventually gets built with g++, not gcc:

  /tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/./prev-gcc/g++ -B/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/./prev-gcc/ -B/nix/store/glikf0cfxhhswagdh7wdwgmp20n9bfcl-gcc-debug-4.7.0rc20120302/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/gcc-4.7.0-RC-20120302/libstdc++-v3/libsupc++ -L/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/nix-build-djlxw37gcj9gy88ya1550crn49fpzqck-gcc-debug-4.7.0rc20120302.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c   -O2 -g -I/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/include -B/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib/ -idirafter /nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/include -idirafter /nix/store/fghwm2dz41sz9b2l87ffgv11zadq7dxr-gcc-4.6.3/lib/gcc/*/*/include-fixed  -Wl,-L/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib -Wl,-rpath -Wl,/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib -Wl,-L/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib -Wl,-dynamic-linker -Wl,/nix/store/6cgraa4mxbg1gfi95a4yhxq6yzb56s4v-glibc-2.13/lib/ld-linux-x86-64.so.2 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7.0-RC-20120302/gcc -I../../gcc-4.7.0-RC-20120302/gcc/. -I../../gcc-4.7.0-RC-20120302/gcc/../include -I../../gcc-4.7.0-RC-20120302/gcc/../libcpp/include -I/nix/store/z5hcwkvzbzhy85lm3ibxzqmal22jgjwj-gmp-5.0.3/include -I/nix/store/xjks1ifzrh9ylnsjj15sy267r30b1ca5-mpfr-3.1.0/include -I/nix/store/36b2ghjhi40gyzfqx0qqqc034mc3ziii-mpc-0.9/include  -I../../gcc-4.7.0-RC-20120302/gcc/../libdecnumber -I../../gcc-4.7.0-RC-20120302/gcc/../libdecnumber/bid -I../libdecnumber -I/nix/store/3fk4lylmhsyqkq2vna2gqwssgfr51ynd-ppl-0.11.2/include  -I/nix/store/gq2pi083kf1vkl48j0wigpqzhga0bx9v-cloog-0.16.3/include -DCLOOG_INT_GMP -DCLOOG_ORG  ../../gcc-4.7.0-RC-20120302/gcc/tree.c -o tree.o

I believe this is not intentional, right?

What am I doing wrong?

Thanks,
Ludo’.

[0] Full log at <http://hydra.nixos.org/build/2267886/nixlog/1/raw>.

[Andrew Pinski-2]

2012/3/9 Ludovic Courtès <ludovic.courtes@...>:

> I believe this is not intentional, right?

No, this is intentional.  We bootstrap the compiler using the C++
front-end now.  We build stage1 with the C compiler and then build
stages 2 and 3 with the C++ compiler.

This is a documented change too.

Thanks,
Andrew Pinski

[Jakub Jelinek]

On Fri, Mar 09, 2012 at 01:53:52AM -0800, Andrew Pinski wrote:
> 2012/3/9 Ludovic Courtès <ludovic.courtes@...>:
>
> > I believe this is not intentional, right?
>
> No, this is intentional.  We bootstrap the compiler using the C++
> front-end now.  We build stage1 with the C compiler and then build
> stages 2 and 3 with the C++ compiler.
>
> This is a documented change too.

You can configure with --disable-build-poststage1-with-cxx
to disable that (or --disable-build-with-cxx in addition
to that, but that is the default in 4.7).

        Jakub

[Ludovic Courtès-4]

Hi,

Andrew Pinski <pinskia@...> skribis:

> 2012/3/9 Ludovic Courtès <ludovic.courtes@...>:
>
>> I believe this is not intentional, right?
>
> No, this is intentional.  We bootstrap the compiler using the C++
> front-end now.  We build stage1 with the C compiler and then build
> stages 2 and 3 with the C++ compiler.

OK.

However, this means that plug-ins must now be built with g++, except
when GCC was configured with --disable-build-poststage1-with-cxx.  This
seems difficult to deal with, for plug-in writers.

Is there a recommended approach for plug-ins?  (I couldn’t find one at
<http://gcc.gnu.org/gcc-4.7/changes.html>.)

Thanks,
Ludo’.

[Ludovic Courtès-4]

Hi,

ludovic.courtes@... (Ludovic Courtès) skribis:

> Andrew Pinski <pinskia@...> skribis:
>
>> 2012/3/9 Ludovic Courtès <ludovic.courtes@...>:
>>
>>> I believe this is not intentional, right?
>>
>> No, this is intentional.  We bootstrap the compiler using the C++
>> front-end now.  We build stage1 with the C compiler and then build
>> stages 2 and 3 with the C++ compiler.
>
> OK.
>
> However, this means that plug-ins must now be built with g++, except
> when GCC was configured with --disable-build-poststage1-with-cxx.  This
> seems difficult to deal with, for plug-in writers.

I’m really concerned about the maintenance difficulties that this change
entails for external plug-ins.

Would something along these lines be acceptable at this stage?


diff --git a/gcc/tree.h b/gcc/tree.h
index 0a2d619..ce7acf2 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -22,6 +22,10 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef GCC_TREE_H
 #define GCC_TREE_H
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 #include "hashtab.h"
 #include "machmode.h"
 #include "input.h"
@@ -6102,4 +6106,8 @@ builtin_decl_implicit_p (enum built_in_function fncode)
   && builtin_info.implicit_p[uns_fncode]);
 }
 
+#ifdef __cplusplus
+}
+#endif
+
 #endif  /* GCC_TREE_H  */


(The same should be applied to all the headers listed in
‘PLUGIN_HEADERS’, at least.)

Or was it already considered and rejected?

Thanks,
Ludo’.

[Duncan Sands]

Hi,

>>>> I believe this is not intentional, right?
>>>
>>> No, this is intentional.  We bootstrap the compiler using the C++
>>> front-end now.  We build stage1 with the C compiler and then build
>>> stages 2 and 3 with the C++ compiler.
>>
>> OK.
>>
>> However, this means that plug-ins must now be built with g++, except
>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>> seems difficult to deal with, for plug-in writers.
>
> I’m really concerned about the maintenance difficulties that this change
> entails for external plug-ins.

does this mean that if built with --disable-bootstrap then symbols aren't
mangled, while otherwise they are?  I personally don't mind if symbols are
mangled or not, but it would be simpler if symbols can be relied upon to always
be mangled, or always not be mangled...

I guess I could work around it by detecting at build time whether the targeted
gcc has mangled symbols, and using extern "C" only if not mangled.  It would
help if there was a simple way to ask gcc if it is using mangled symbols or not.

Ciao, Duncan.

[Ian Lance Taylor-3]

ludovic.courtes@... (Ludovic Courtès) writes:

> However, this means that plug-ins must now be built with g++, except
> when GCC was configured with --disable-build-poststage1-with-cxx.  This
> seems difficult to deal with, for plug-in writers.

This is an unfortunate truth during our transition to building gcc with
C++.  There is going to be a period of time when the compiler may be
built as either C or C++.  The end goal is for the compiler to always be
built with C++, but until we reach that state I think plugin writers
will have to test.

Ian

[Ludovic Courtès-4]

Ian Lance Taylor <iant@...> skribis:

> ludovic.courtes@... (Ludovic Courtès) writes:
>
>> However, this means that plug-ins must now be built with g++, except
>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>> seems difficult to deal with, for plug-in writers.
>
> This is an unfortunate truth during our transition to building gcc with
> C++.  There is going to be a period of time when the compiler may be
> built as either C or C++.  The end goal is for the compiler to always be
> built with C++, but until we reach that state I think plugin writers
> will have to test.

What about wrapping the C API in extern "C"?

Thanks,
Ludo’.

[Ian Lance Taylor-3]

ludovic.courtes@... (Ludovic Courtès) writes:

> Ian Lance Taylor <iant@...> skribis:
>
>> ludovic.courtes@... (Ludovic Courtès) writes:
>>
>>> However, this means that plug-ins must now be built with g++, except
>>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>>> seems difficult to deal with, for plug-in writers.
>>
>> This is an unfortunate truth during our transition to building gcc with
>> C++.  There is going to be a period of time when the compiler may be
>> built as either C or C++.  The end goal is for the compiler to always be
>> built with C++, but until we reach that state I think plugin writers
>> will have to test.
>
> What about wrapping the C API in extern "C"?

We eventually will want the internal APIs to be C++, so this transition
will inevitably happen at some point.

I agree that the well-defined plugin API should be extern "C", and
indeed plugin-api.h does use extern "C".  Unfortunately, as we all know,
plugins need to use more than the well-defined API.

Ian

[Ludovic Courtès-4]

Ian Lance Taylor <iant@...> skribis:

> ludovic.courtes@... (Ludovic Courtès) writes:
>
>> Ian Lance Taylor <iant@...> skribis:
>>
>>> ludovic.courtes@... (Ludovic Courtès) writes:
>>>
>>>> However, this means that plug-ins must now be built with g++, except
>>>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>>>> seems difficult to deal with, for plug-in writers.
>>>
>>> This is an unfortunate truth during our transition to building gcc with
>>> C++.  There is going to be a period of time when the compiler may be
>>> built as either C or C++.  The end goal is for the compiler to always be
>>> built with C++, but until we reach that state I think plugin writers
>>> will have to test.
>>
>> What about wrapping the C API in extern "C"?
>
> We eventually will want the internal APIs to be C++, so this transition
> will inevitably happen at some point.

I understand the goal.  However, should a C++ API be added, the C-only
part could still be kept extern "C".

For 4.7.0, as Duncan Sands writes, it would be a very helpful for the
ABI to be independent of configuration options–i.e., either mangled or
unmangled symbols.

WDYT?

Thanks,
Ludo’.

[Ian Lance Taylor-3]

ludovic.courtes@... (Ludovic Courtès) writes:

> Ian Lance Taylor <iant@...> skribis:
>
>> ludovic.courtes@... (Ludovic Courtès) writes:
>>
>>> Ian Lance Taylor <iant@...> skribis:
>>>
>>>> ludovic.courtes@... (Ludovic Courtès) writes:
>>>>
>>>>> However, this means that plug-ins must now be built with g++, except
>>>>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>>>>> seems difficult to deal with, for plug-in writers.
>>>>
>>>> This is an unfortunate truth during our transition to building gcc with
>>>> C++.  There is going to be a period of time when the compiler may be
>>>> built as either C or C++.  The end goal is for the compiler to always be
>>>> built with C++, but until we reach that state I think plugin writers
>>>> will have to test.
>>>
>>> What about wrapping the C API in extern "C"?
>>
>> We eventually will want the internal APIs to be C++, so this transition
>> will inevitably happen at some point.
>
> I understand the goal.  However, should a C++ API be added, the C-only
> part could still be kept extern "C".

We are talking here about internal GCC functions.  We are not talking
about an actual defined API.  The defined API is in plugin-api.h, and
that remains extern "C".  There is no "C-only part" of the internal API.


> For 4.7.0, as Duncan Sands writes, it would be a very helpful for the
> ABI to be independent of configuration options–i.e., either mangled or
> unmangled symbols.

That just postpones the pain to gcc 4.8.0.

Ian

[David Malcolm]

On Fri, 2012-03-09 at 11:41 +0100, Ludovic Courtès wrote:

> Hi,
>
> Andrew Pinski <pinskia@...> skribis:
>
> > 2012/3/9 Ludovic Courtès <ludovic.courtes@...>:
> >
> >> I believe this is not intentional, right?
> >
> > No, this is intentional.  We bootstrap the compiler using the C++
> > front-end now.  We build stage1 with the C compiler and then build
> > stages 2 and 3 with the C++ compiler.

Aha - we've been running into problems with this when people try to
build the gcc python plugin on different distibution's builds of gcc [1]

> OK.
>
> However, this means that plug-ins must now be built with g++, except
> when GCC was configured with --disable-build-poststage1-with-cxx.  This
> seems difficult to deal with, for plug-in writers.

Agreed; this makes life much more difficult for GCC plugins.

Dave

[1]
https://fedorahosted.org/pipermail/gcc-python-plugin/2012-March/000203.html

[Ludovic Courtès-4]

Hi,

Ian Lance Taylor <iant@...> skribis:

> ludovic.courtes@... (Ludovic Courtès) writes:
>
>> Ian Lance Taylor <iant@...> skribis:
>>
>>> ludovic.courtes@... (Ludovic Courtès) writes:
>>>
>>>> Ian Lance Taylor <iant@...> skribis:
>>>>
>>>>> ludovic.courtes@... (Ludovic Courtès) writes:
>>>>>
>>>>>> However, this means that plug-ins must now be built with g++, except
>>>>>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>>>>>> seems difficult to deal with, for plug-in writers.
>>>>>
>>>>> This is an unfortunate truth during our transition to building gcc with
>>>>> C++.  There is going to be a period of time when the compiler may be
>>>>> built as either C or C++.  The end goal is for the compiler to always be
>>>>> built with C++, but until we reach that state I think plugin writers
>>>>> will have to test.
>>>>
>>>> What about wrapping the C API in extern "C"?
>>>
>>> We eventually will want the internal APIs to be C++, so this transition
>>> will inevitably happen at some point.
>>
>> I understand the goal.  However, should a C++ API be added, the C-only
>> part could still be kept extern "C".
>
> We are talking here about internal GCC functions.  We are not talking
> about an actual defined API.  The defined API is in plugin-api.h, and
> that remains extern "C".  There is no "C-only part" of the internal API.

Hmm <plugin-api.h> is for linker plug-ins; <gcc-plugin.h> provides
nothing more than the event mechanism.

Symbols declared in <tree.h> are mangled, for instance.  I’m not sure
whether <tree.h> is considered internal or not, but I can hardly see
what kind of plug-in could be written without using it.

>> For 4.7.0, as Duncan Sands writes, it would be a very helpful for the
>> ABI to be independent of configuration options–i.e., either mangled or
>> unmangled symbols.
>
> That just postpones the pain to gcc 4.8.0.

In 4.8 things will be easier: plug-ins will have to be compiled with g++.

In 4.7, finding out whether gcc or g++ should be used is left as an
exercise to the plug-in writer, which is inconvenient at best.

Thanks,
Ludo’.

[Richard Guenther-2]

2012/3/12 Ludovic Courtès <ludovic.courtes@...>:

> Hi,
>
> Ian Lance Taylor <iant@...> skribis:
>
>> ludovic.courtes@... (Ludovic Courtès) writes:
>>
>>> Ian Lance Taylor <iant@...> skribis:
>>>
>>>> ludovic.courtes@... (Ludovic Courtès) writes:
>>>>
>>>>> Ian Lance Taylor <iant@...> skribis:
>>>>>
>>>>>> ludovic.courtes@... (Ludovic Courtès) writes:
>>>>>>
>>>>>>> However, this means that plug-ins must now be built with g++, except
>>>>>>> when GCC was configured with --disable-build-poststage1-with-cxx.  This
>>>>>>> seems difficult to deal with, for plug-in writers.
>>>>>>
>>>>>> This is an unfortunate truth during our transition to building gcc with
>>>>>> C++.  There is going to be a period of time when the compiler may be
>>>>>> built as either C or C++.  The end goal is for the compiler to always be
>>>>>> built with C++, but until we reach that state I think plugin writers
>>>>>> will have to test.
>>>>>
>>>>> What about wrapping the C API in extern "C"?
>>>>
>>>> We eventually will want the internal APIs to be C++, so this transition
>>>> will inevitably happen at some point.
>>>
>>> I understand the goal.  However, should a C++ API be added, the C-only
>>> part could still be kept extern "C".
>>
>> We are talking here about internal GCC functions.  We are not talking
>> about an actual defined API.  The defined API is in plugin-api.h, and
>> that remains extern "C".  There is no "C-only part" of the internal API.
>
> Hmm <plugin-api.h> is for linker plug-ins; <gcc-plugin.h> provides
> nothing more than the event mechanism.
>
> Symbols declared in <tree.h> are mangled, for instance.  I’m not sure
> whether <tree.h> is considered internal or not, but I can hardly see
> what kind of plug-in could be written without using it.
>
>>> For 4.7.0, as Duncan Sands writes, it would be a very helpful for the
>>> ABI to be independent of configuration options–i.e., either mangled or
>>> unmangled symbols.
>>
>> That just postpones the pain to gcc 4.8.0.
>
> In 4.8 things will be easier: plug-ins will have to be compiled with g++.
>
> In 4.7, finding out whether gcc or g++ should be used is left as an
> exercise to the plug-in writer, which is inconvenient at best.

Well, that is what you get for having plugins without a proper plugin API ;)
It's not going to change for 4.7.  Anybody who is willing to attack the
fundamental plugin issue is advised to develop a separate, stable
(and thus forward-looking) C plugin interface (and make all other
symbols hidden again).

Richard.

> Thanks,
> Ludo’.

[Gabriel Dos Reis]

On Mon, Mar 12, 2012 at 3:56 AM, Ludovic Courtès
<ludovic.courtes@...> wrote:

> Symbols declared in <tree.h> are mangled, for instance.  I’m not sure
> whether <tree.h> is considered internal or not, but I can hardly see
> what kind of plug-in could be written without using it.

tree.h is internal.

-- Gaby

[Gabriel Dos Reis]

On Mon, Mar 12, 2012 at 7:10 AM, Richard Guenther
<richard.guenther@...> wrote:

>> In 4.7, finding out whether gcc or g++ should be used is left as an
>> exercise to the plug-in writer, which is inconvenient at best.
>
> Well, that is what you get for having plugins without a proper plugin API ;)
> It's not going to change for 4.7.  Anybody who is willing to attack the
> fundamental plugin issue is advised to develop a separate, stable
> (and thus forward-looking) C plugin interface (and make all other
> symbols hidden again).

I thought people who were using the plugins in its current form understood
that things could change from release to release.

-- Gaby

[Ludovic Courtès-4]

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?

Thanks,
Ludo’.

[0] https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=6090&r2=6195

[Richard Guenther-2]

2012/3/16 Ludovic Courtès <ludovic.courtes@...>:
> 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.

Richard.

> Thanks,
> Ludo’.
>
> [0] https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=6090&r2=6195

[Ludovic Courtès-4]

Hi,

Richard Guenther <richard.guenther@...> skribis:

> 2012/3/16 Ludovic Courtès <ludovic.courtes@...>:
>> 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.

Thanks,
Ludo’.

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

[Richard Guenther-2]

2012/3/16 Ludovic Courtès <ludovic.courtes@...>:

> Hi,
>
> Richard Guenther <richard.guenther@...> skribis:
>
>> 2012/3/16 Ludovic Courtès <ludovic.courtes@...>:
>>> 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