GCC 4.7.0RC: Mangled names in cc1

GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

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>.

Re: GCC 4.7.0RC: Mangled names in cc1

[Andrew Pinski]

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

> 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

Re: GCC 4.7.0RC: Mangled names in cc1

[Jakub Jelinek]

On Fri, Mar 09, 2012 at 01:53:52AM -0800, Andrew Pinski wrote:
> 2012/3/9 Ludovic Courtès <ludovic.courtes@inria.fr>:
> 
> > 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

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hi,

Andrew Pinski <pinskia@gmail.com> skribis:

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

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Hi,

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

> Andrew Pinski <pinskia@gmail.com> skribis:
>
>> 2012/3/9 Ludovic Courtès <ludovic.courtes@inria.fr>:
>>
>>> 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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 510 bytes --]

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  */

[-- Attachment #3: Type: text/plain, Size: 162 bytes --]


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

Or was it already considered and rejected?

Thanks,
Ludo’.

Re: GCC 4.7.0RC: Mangled names in cc1

[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.

Re: GCC 4.7.0RC: Mangled names in cc1

[Ian Lance Taylor]

ludovic.courtes@inria.fr (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

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

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

> ludovic.courtes@inria.fr (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’.

Re: GCC 4.7.0RC: Mangled names in cc1

[Ian Lance Taylor]

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

> Ian Lance Taylor <iant@google.com> skribis:
>
>> ludovic.courtes@inria.fr (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

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

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

> ludovic.courtes@inria.fr (Ludovic Courtès) writes:
>
>> Ian Lance Taylor <iant@google.com> skribis:
>>
>>> ludovic.courtes@inria.fr (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’.

Re: GCC 4.7.0RC: Mangled names in cc1

[Ian Lance Taylor]

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

> Ian Lance Taylor <iant@google.com> skribis:
>
>> ludovic.courtes@inria.fr (Ludovic Courtès) writes:
>>
>>> Ian Lance Taylor <iant@google.com> skribis:
>>>
>>>> ludovic.courtes@inria.fr (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

Re: GCC 4.7.0RC: Mangled names in cc1

[David Malcolm]

On Fri, 2012-03-09 at 11:41 +0100, Ludovic Courtès wrote:
> Hi,
> 
> Andrew Pinski <pinskia@gmail.com> skribis:
> 
> > 2012/3/9 Ludovic Courtès <ludovic.courtes@inria.fr>:
> >
> >> 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

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hi,

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

> ludovic.courtes@inria.fr (Ludovic Courtès) writes:
>
>> Ian Lance Taylor <iant@google.com> skribis:
>>
>>> ludovic.courtes@inria.fr (Ludovic Courtès) writes:
>>>
>>>> Ian Lance Taylor <iant@google.com> skribis:
>>>>
>>>>> ludovic.courtes@inria.fr (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’.

Re: GCC 4.7.0RC: Mangled names in cc1

[Richard Guenther]

2012/3/12 Ludovic Courtès <ludovic.courtes@inria.fr>:
> Hi,
>
> Ian Lance Taylor <iant@google.com> skribis:
>
>> ludovic.courtes@inria.fr (Ludovic Courtès) writes:
>>
>>> Ian Lance Taylor <iant@google.com> skribis:
>>>
>>>> ludovic.courtes@inria.fr (Ludovic Courtès) writes:
>>>>
>>>>> Ian Lance Taylor <iant@google.com> skribis:
>>>>>
>>>>>> ludovic.courtes@inria.fr (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’.

Re: GCC 4.7.0RC: Mangled names in cc1

[Gabriel Dos Reis]

On Mon, Mar 12, 2012 at 3:56 AM, Ludovic Courtès
<ludovic.courtes@inria.fr> 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

Re: GCC 4.7.0RC: Mangled names in cc1

[Gabriel Dos Reis]

On Mon, Mar 12, 2012 at 7:10 AM, Richard Guenther
<richard.guenther@gmail.com> 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

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

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

Re: GCC 4.7.0RC: Mangled names in cc1

[Richard Guenther]

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.

Richard.

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

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

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.

Thanks,
Ludo’.

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

Re: GCC 4.7.0RC: Mangled names in cc1

[Richard Guenther]

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

Re: GCC 4.7.0RC: Mangled names in cc1

[Basile Starynkevitch]

On Fri, Mar 16, 2012 at 02:04:38PM +0100, Ludovic Courtès wrote:
> 
> 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.

Well, if your plugin is compiled with C++ and all of GCC is also compiled with C++, you might not need interoperability.

> 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


By the way, your plugin could be an interesting case for MELT, which
obviously provide higher-level functions (since MELT functions are true
closures).

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hello,

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

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

[...]

> Well, if you invent new paradigms

Hmm, I didn’t invent anything here.

> 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?

Sure, even Guile-GCC [0].  :-)

(Speaking of which, since it mostly uses Guile’s dynamic FFI to
interface with GCC, and thus dlsyms GCC’s symbols, it will also suffer
from the transition.  How does the Python plug-in handle that?  Is it
written in ANSI C, or does it use ctypes?)

Nevertheless, I found that GNU C provides a nice middle ground.

> 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.

That would be great, but I’d like to support 4.5 and 4.6 as well.

Thanks,
Ludo’.

[0] https://gitorious.org/guile-gcc/guile-gcc

Re: GCC 4.7.0RC: Mangled names in cc1

[Gabriel Dos Reis]

On Fri, Mar 16, 2012 at 6:03 AM, Ludovic Courtès
<ludovic.courtes@inria.fr> wrote:
> 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?

Patient: Doctor, it hurts when I do this.  Do you have a medication?
Doctor: Yes, don't do it.


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

Re: GCC 4.7.0RC: Mangled names in cc1

[Gabriel Dos Reis]

On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès
<ludovic.courtes@inria.fr> wrote:

> Right, but the nice thing with GCC plug-ins is they can be implemented
> using all GNU extensions.

at the risk of having this very discussion.

[...]

> 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.

Does not compute.  If you are using nested functions, you are not
interested in C interoperability in the first place.

GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[David Malcolm]

On Fri, 2012-03-16 at 16:17 +0100, Ludovic Courtès wrote:
> Hello,
> 
> Richard Guenther <richard.guenther@gmail.com> skribis:
> 
> > 2012/3/16 Ludovic Courtès <ludovic.courtes@inria.fr>:
> 
> [...]
> 
> > Well, if you invent new paradigms
> 
> Hmm, I didn’t invent anything here.
> 
> > 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?
> 
> Sure, even Guile-GCC [0].  :-)
> 
> (Speaking of which, since it mostly uses Guile’s dynamic FFI to
> interface with GCC, and thus dlsyms GCC’s symbols, it will also suffer
> from the transition.  How does the Python plug-in handle that?  Is it
> written in ANSI C, or does it use ctypes?)

The python plugin is written in plain C, much of it autogenerated.  It
mostly dynamically links to GCC, but uses weak references on some of
GCC's symbols (e.g. when using symbols that only exist in the C++
frontend), so we'll see how well that works.

I have to admit to being nervous about the GCC change to C++.
Elaborating on this further may degenerate into a rant, so here goes,
and I apologize in advance.

I should stress at the this point that I don't speak for Red Hat here;
this is just my own opinion (based on having spent much of the last year
working on the gcc python plugin, and having spent many years involved
in free software).

The C++ move is making things more difficult for plugin authors, but
that's a symptom of not having a plugin API.

It's perfectly possible to write clean, maintainable code in C that
implements object-oriented ideas such as information hiding, dynamic
dispatch according to type, and so on.  See e.g. CPython or GObject for
examples.

What I'm really hoping for from GCC is a move towards a collection of
libraries that can be embedded in (license-compatible) apps: LLVM is
gaining ground for the use case of programs that need JIT-compilation
(e.g. the X server, or a JVM).  I appreciate that JIT compilation has
different characteristics to a classic ahead-of-time compiler.

C++ is likely to make it more difficult to embed GCC into such apps
(e.g. nasty ordering issues for globals with non-empty constructors; ABI
differences e.g. relating to exception handling; extra complexity of
linking); everyone large free software that uses C++ chooses a subset of
the language to use (this could be enforced with a plugin to the
compiler!)

What use cases would a rearchitected GCC have?  I may not win friends
here by posting this link, but, to be frank, see:
  http://llvm.org/ProjectsWithLLVM/
Some examples:
  * the X server: llvmpipe is a software implementation of OpenGL:
compiling OpenGL shader programs into machine code for the CPU for the
case where the GPU isn't up to the job (or for which the vendor isn't
providing specs).
  * IcedTea is using LLVM to add JIT compilation for Java code (see
http://icedtea.classpath.org/wiki/ZeroSharkFaq#Why_was_Shark_written.3F
)
  * JIT compilation within dynamic languages: e.g. Unladen Swallow
(though that's a dead project; most of the time and energy was spent
fixing bugs in LLVM)
  * static analysis tools
  * anywhere we're writing plugins.  Building standalone tools and just
linking is often preferable.  See e.g.:
http://blogs.gnome.org/jessevdk/2011/09/10/gedit-clang-plugin-progress/
where (if I'm reading it right) the gedit editor has gained a plugin
that embeds parts of LLVM.


Proposed outcome
----------------
GCC becomes a family of shared libraries that can be dynamically and
statically linked.  The executables become a thin wrapper that invoke
these libraries (perhaps statically linked to minimize startup costs).

Note that I'm *not* proposing a license change.  The code that uses
these libraries would need to be license-compatible with GCC.

The ideal outcome would be to dynamically link this code into a
multi-threaded process, in which multiple dynamically-linked libraries
within the process are linked against the GCC library, working
independently, without knowing that each one is using the library.

Such an reorganization could be worthy of bump to the major-release id
(e.g. "gcc 5")

Current architectural issues
-----------------------------
GCC is currently a large body of single-threaded code that is compiled
and linked into multiple large executables. 

Issues:
* lots of global state: global variables, static locals, etc.
* related to the above: function often have side-effects
* memory management: custom allocator, with garbage collection.  I'm not
sure how the GC code locates roots on the stack, and I suspect that's
there's currently an assumption there there aren't multiple threads
within the process
* process termination: code can call abort() to handle errors, rather
than being able to report back an error state.  It may be acceptable for
a standalone executable to call "abort", but it's not acceptable when a
library that you're calling into does (e.g. if the X server is using
such a library, your desktop goes away...)
* actual machine-code generation is currently done by the GNU assembler:
would need to turn that into a shared library as well (turning GNU
assembler into a thin wrapper around that library)
* no namespacing: seemingly arbitrary naming convention for symbols.
Would want to add some namespace prefix to the public symbols (vars and
fns), and to the types.
* JIT compilation vs AOT compilation: when an app embeds a JIT it would
want to assemble a more appropriate set of compilation passes
dynamically, I suspect, compared to the full set of AOT passes that GCC
currently has.
* plugin architecture: how would plugins relate to this rearchitected
GCC?
* option-handling is currently very tied to the command line.  Multiple
uses of the library might want different option sets.
* threading?  potentially one could punt this by adding a "Big Compiler
Lock": one big mutex guarding all usage of the APIs.
* the political will to do this
* actually implementing the thing!

It seems that GCC has provided an API for registering plugins, but no
API for the plugins to then actually use...  Perhaps the C++ move would
be alleviated by having an actually C API for plugins to use?  I started
writing a possible API for plugins, the idea being to port my python
plugin to this as a middle layer, but it strikes me that this could also
be used for the embedding case as well.  So perhaps the first step might
be to implement the plugin API, and that could evolve into the
inter-library API that the different parts of a more modular GCC could
use to talk to each other?

The proposed API might look like this:

/*
  Pure C for maximum compatibility
  All macros begin with a "GCC_" prefix
  All symbols begin with a "gcc_" prefix with _ separators, though I
  happen to prefer the CPython style (e.g. "GccBasicBlock_GetIndex");
  bikeshed away!
  (You may only call such a symbol when you have the Big GCC Lock?)
  All types begin with a "gcc_" prefix (again, I'd prefer CPython style
  e.g. "struct GccBasicBlock").
  How acceptable is it to autogenerate parts of the API? (this is what
  I do in my python plugin; naturally I use python for this).
*/
	
/* Compatibility macros: */
#define GCC_API(RETURN_TYPE) extern RETURN_TYPE

/* All types are opaque; internally these might simply embed one of
gcc's real types as its single field; integration with GC could be
interesting though: */
typedef struct gcc_cfg gcc_cfg;
typedef struct gcc_basic_block gcc_basic_block;
typedef struct gcc_edge gcc_edge;

/* Declarations: control flow graphs */

/* gcc_cfg: */
GCC_API(gcc_basic_block *)
gcc_cfg_get_entry(gcc_cfg *cfg);

GCC_API(gcc_basic_block *)
gcc_cfg_get_exit(gcc_cfg *cfg);

/* gcc_basic_block: */
GCC_API(int)
gcc_basic_block_get_index(const gcc_basic_block *bb);

/* gcc_edge: */
GCC_API(gcc_basic_block *)
gcc_edge_get_src(gcc_edge *e);

GCC_API(gcc_basic_block *)
gcc_edge_get_dest(gcc_edge *e);

/* ...etc... */


Again, these opinions are my own, and not those of Red Hat.

Hope this is constructive.
Dave

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Diego Novillo]

On Fri, Mar 16, 2012 at 13:19, David Malcolm <dmalcolm@redhat.com> wrote:

> Hope this is constructive.

It is.

Parts of your proposal are instances of the modularity effort that has
been going on for some time.  It also touches on some of the same
topics discussed in http://gcc.gnu.org/wiki/ImprovementProjects.

It would be great if you could add this to that page so we can keep
all these ideas in a centralized location.


Thanks.  Diego.

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Gabriel Dos Reis]

On Fri, Mar 16, 2012 at 12:19 PM, David Malcolm <dmalcolm@redhat.com> wrote:

> C++ is likely to make it more difficult to embed GCC into such apps
> (e.g. nasty ordering issues for globals with non-empty constructors;

If you were going to write an API in C and you have no globals that
require a dynamic initialization, there is not reason you would need
one just because you use C++.

-- Gaby

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Joseph S. Myers]

On Fri, 16 Mar 2012, David Malcolm wrote:

> Proposed outcome
[...]
> Current architectural issues
[...]

Not many people commented on the architectural goals document Diego and I 
posted at <http://gcc.gnu.org/ml/gcc/2011-12/msg00103.html>.  Many of your 
ideas seem potentially useful additions to it.  I hope Diego will have 
time soon to push more of the goals and development conventions through 
community approval and move them to the main website; as we do this, 
detailed feedback from people interested in these issues is certainly 
welcome.

> * no namespacing: seemingly arbitrary naming convention for symbols.
> Would want to add some namespace prefix to the public symbols (vars and
> fns), and to the types.

Namespaces are one thing that could well be addressed using C++ namespaces 
(both for GCC itself, and for particular areas within it).

> * actually implementing the thing!

Yes.  Agreement on general goals is certainly useful; it provides an 
overall context for patch review so a modularity patch doesn't get 
unhelpful comments to the effect that "this whole modularity idea is 
ill-conceived".  But what's really needed is the investment of many 
person-years in improvements directed towards well-defined goals.

> It seems that GCC has provided an API for registering plugins, but no
> API for the plugins to then actually use...  Perhaps the C++ move would

As regards the limited number of places where plugins get called, the idea 
(I think) is that as and when a plugin author wants plugins to be involved 
at a particular point in GCC, they should contribute appropriate patches 
(rather than GCC developers speculatively guessing what plugins might 
want).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Jonathan Wakely]

On 16 March 2012 17:19, David Malcolm wrote:
>
> What I'm really hoping for from GCC is a move towards a collection of
> libraries that can be embedded in (license-compatible) apps: LLVM is
> gaining ground for the use case of programs that need JIT-compilation
> (e.g. the X server, or a JVM).  I appreciate that JIT compilation has
> different characteristics to a classic ahead-of-time compiler.
>
> C++ is likely to make it more difficult to embed GCC into such apps

It seems to work for LLVM and Clang.

GCC 5 & modularity

[Basile Starynkevitch]

On Fri, 16 Mar 2012 19:41:56 +0000 (UTC)
"Joseph S. Myers" <joseph@codesourcery.com> wrote:

> On Fri, 16 Mar 2012, David Malcolm wrote:
> 
> > Proposed outcome
> [...]
> > Current architectural issues
> [...]
> 
> Not many people commented on the architectural goals document Diego and I 
> posted at <http://gcc.gnu.org/ml/gcc/2011-12/msg00103.html>.  Many of your 
> ideas seem potentially useful additions to it.  I hope Diego will have 
> time soon to push more of the goals and development conventions through 
> community approval and move them to the main website; as we do this, 
> detailed feedback from people interested in these issues is certainly 
> welcome.


I wanted many times to comment on these issues, but I am very scared of hurting people.
Last time I spoke of GCC modularity (actually lack of it), some people felt insulted,
which is certainly not my aim. So for many months I was too scared to comment on these
issues.

So if you feel insulted by any mine comments on these issues, please accept my apologies
and recall than I am not a native English speaker, nor was I educated in north American
universities or schools [except that I spent 1 year in California, as an 8 year old kid,
in 1967; but this is not enough a cultural influence, and it was really a long time
ago]. (I'm sure most people here would have difficulties in participating to mailing lists
in French or in Russian, so please be kind with me.)

First, my understanding of modules is that:

   * you can name and count the modules of a software

   * given a source line, or function, you can decide at a glance to which one module it
belongs

   * the interface between modules is well documented

I'm sorry to say that, but current GCC (ie 4.7 or today's trunk) is *not* modular. Don't
feel injured by that fact. Indeed, GCC is a little less messy than it was a few years
ago, but being less messy is not being modular IMHO. And something cannot be
"half-modular". 

A good modular software is the Gnome/GTK "graphical interface" system (ok, it is not a
compiler), and probably the KDE/Qt one. When you start learning it, you get a nice figure
http://developer.gnome.org/ and sort of list of modules
http://developer.gnome.org/platform-overview/stable/ ; we have absolutely nothing of that
sort for GCC today. We cannot even think of a similar figure for GCC today.


So I would be delighted if GCC was made of modules. But I have no idea of how that can be
done. I would like global GCC experts to propose an organization of modules. This means
that "global reviewers" type of experts would suggest at first:

 * A set of (a dozen or two) modules, each having a *name* and a short *description*
(perhaps a single title phrase at first).

 * An imprecise mapping of functionalities or features, or preferably of current source
files to modules

Don't expect non-global GCC maintainers to provide such a list; you need to have an
overall view of GCC to think of such a list; and very few people have such a global view;
I (Basile) certainly don't have it: there are lots of parts of GCC I don't know about! 
Of course, I may have an opinion on a particular proposed set of modules (but I don't
feel knowledgeable enough about all GCC to propose one).


 And making the current GCC core base modular is not easy (it might be impossible),
because we cannot decide at a glance to what module a given current code should belong.
An important thing if we want to go modular is to define a road-map and probably to
accept the fact that, if GCC 5 is a modular GCC, is will have less functionalities, less
optimizations, less power than the current GCC 4.7: we probably would have to
temporarily drop some feature or power from GCC to make it modular (otherwise, that would
be too gigantic an effort). I have no idea if we can do that (this is why I am sometimes
pessimistic); probably most GCC contributors are paid by companies which might not afford
that.

I do believe that identifiers in GCC should be organized in such a way that the module
they belong to is visible at once. I think that a prefix (à la GTK) or a C++ namespace
should be great. In particular, this means that most GCC identifiers should change
(which means that any such evolution is not syntactically gradual; it has to be made by
huge, but "easy", patches). 

I would prefer much more that tree-s would be named foobar::tree in C++ or foobar_tree in
C, where foobar is the name of the module defining trees and providing a API to
manipulate them. I strongly want that all GCC names would change in a more organized way.
It is a real pain, even with today's tools, to understand where are tree-s or edge-s or
basic_block-s defined.

GCC is not only a big bunch of source code, but also a set of "meta-programming" tools ie
a set of generators. And it is good we have them (I certainly don't think we should
remove them, and I am not naive enough to believe or want them to be replaced by tricky
templates in C++). Again, all GCC internal code generators should be listed (it is still
difficult to find an up-to-date list) and well documented.

My belief is that GCC should aim to be hosted on today's machines. This means that we
should use notably: shared libraries (we have almost none of them inside GCC) which can
map nicely to modules (like GTK does), and probably a richer system interface than what
the language standards provide. Libiberty is not enough: it cannot be even used by
plugins. Perhaps we could choose some foundational module (like perhaps Glib or something
else) providing small abstractions of system facilities. We also need GCC to really have
plugins (ie give up the idea of a plugin-less GCC, which is useless). And we should have
enough modularity so that each module could be extended or perhaps even superseded by an
external plugin. If modules are plugins or shared libraries, then extending or adding them
is easier, and working on GCC is faster.

We should also define a set of non-modular, ie global, features or traits for GCC. I am
in particular thinking about:

   * Naming conventions

   * a garbage collector. Even a modular GCC need some memory management policy (and
ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO inside a compiler
because a compiler has much more complex and circular data structures, and much less
hierarchically organized, that a graphical tookit has). We should define a memory policy
in garbage collector's terms. (and ggc is a very bad GC, it should be improved, not
removed).

   * a set of conventions and a module for "dumping" (like our -fdump... today) and for
program arguments (ie optimization or other flags). I have myself not a precise
understanding of what -fdump means today... (just a feeling of it).

   * a module and set of conventions for diagnostic reporting to the user

   * the requirement that each major internal representation (like Gimple, Tree, ...)
should be dumpable, serializable in a textual way (perhaps JSON or YAML like), and
loadable (so we would have a parser able to construct Gimple in memory from the
serialized textual representation in a faithful manner).

   * a set of conventions regarding our meta-programming code generators (gengtype,
genattr, ..)

   * Meta-data about core types and modules is IMHO very important. The Gobject
introspection machinery of GTK3 made interfacing GTK to external software (in particular,
gluing it to interpreters) much much easier. We should probably have an equivalent thing:
a machine-level formalization of the main GCC APIs and the major GCC internal data. (This
would also help more robust plugins: it could query a particular GCC installation about
the feature it has).

    * Some documentation should be generated from source code (with a comment
convention), like doxygen or something else. (I hope that the license issue is solved on
this).


My feeling is that making GCC modular is a huge task (and we'll have to
accept that some current features would be first dropped to make it feasible). I have no
idea if it is realistic. (But I feel that in the long run, if GCC is remaining
non-modular, it will attract fewer and fewer new developers and gradually will become
less and less relevant).


My first wish is that someone (a "global reviewer" probably) would propose a tentative
list of modules to discuss.


I hope I did not hurt anyone. If I did, please accept my apologies. Feel free to ignore
that email.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: GCC 5 & modularity

[Robert Dewar]

On 3/18/2012 12:56 PM, Basile Starynkevitch wrote:

>     * you can name and count the modules of a software

Well in a hierarchical system this is not so clear, since modules may
exist at different levels of abstraction. For instance in a compiler,
at one level of abstraction, the front end is a module, at another
level of abstraction, e.g. in the compiler, the semantic analysis for
chapter 7 constructs in the RM could be considered as a module.
>
>     * given a source line, or function, you can decide at a glance to which one module it
> belongs

This seems totally bogus, if you have something like

     n++;

you can't tell what module that belongs to, and if your idea is that
all variables should be long enough to know immediately what module
something is in, I would regard that as plain horrible and highly
undesirable.
>
>     * the interface between modules is well documented

Sure that's apple pie and motherhood, so it says nothing
>
> I'm sorry to say that, but current GCC (ie 4.7 or today's trunk) is *not* modular.

Modularity is not a binary quality, so this is not a helpful statement

> Don't
> feel injured by that fact. Indeed, GCC is a little less messy than it was a few years
> ago, but being less messy is not being modular IMHO. And something cannot be
> "half-modular".

Absolutely it can, parts of the system can be arranged nicely into 
modules, and parts of the system may not be.

> So I would be delighted if GCC was made of modules. But I have no idea of how that can be
> done.

Then your comments are not at all helpful, since they just
reflect vague goals which everyone agrees on.

> I do believe that identifiers in GCC should be organized in such a way that the module
> they belong to is visible at once. I think that a prefix (à la GTK) or a C++ namespace
> should be great. In particular, this means that most GCC identifiers should change
> (which means that any such evolution is not syntactically gradual; it has to be made by
> huge, but "easy", patches).

I am of the opinion that this would severely damage readability, it's 
the same sort of thing that leads people in Ada to avoid use clauses
completely.

Since in any decent IDE it's just a single click to find out where a 
variable is declared, it's just noise to include this information in
every variable name. Of course global variables with wide visibility
should have appropriate names, but the idea that all identifiers
should be prefixed is horrible IMO

Re: GCC 5 & modularity

[Basile Starynkevitch]

On Sun, 18 Mar 2012 13:11:05 -0400
Robert Dewar <dewar@adacore.com> wrote:

> On 3/18/2012 12:56 PM, Basile Starynkevitch wrote:
> 
> >     * you can name and count the modules of a software
> 
> Well in a hierarchical system this is not so clear, since modules may
> exist at different levels of abstraction. 

Agreed. Modules could contain submodules (but then I view this more as a language
feature, e.g. Ocaml's modules). I would like first that the GCC community sort-of agree
on a list of a dozen or two modules (call them super-modules or top-level modules if you
like). Obviously such modules would be quite large (since GCC is 5 or 10MLOC, having it
made of 30 modules mean that modules are several hundred thousand lines of source code
each, which means dozens of source files each). I don't think that we should organize GCC
as a large set of non-hierarchical modules: describing GCC as made of 200 top-level
modules won't help newbies to understand it; the description should speak of a
few dozen top-level parts 


> >
> >     * given a source line, or function, you can decide at a glance to which one module it
> > belongs
> 
> This seems totally bogus, if you have something like
> 
>      n++;
> 

I expressed wrongly myself. If you know that 
    n++;
was in file foo/bar.c line 34 [which I meant by a source line, not an isolated set of
tokens newline terminated] you should know that it belongs to some module. Actually, I
believe that modules are a large set of source files (e.g. if GCC was made of two dozens
of modules, each module would probably be made of some dozens of files), so the
requirement is becoming: every source file belongs to exactly one module, and every
module is made of a set of source files.

> you can't tell what module that belongs to, and if your idea is that
> all variables should be long enough to know immediately what module
> something is in, I would regard that as plain horrible and highly
> undesirable.

Long names are relevant only for exported names, usable outside of the module.

> >
> >     * the interface between modules is well documented
> 
> Sure that's apple pie and motherhood, so it says nothing

No, it implies that something which is not documented should not be used outside of the
module (irrespective of any protected: or private: annotations in C++) and this is a
strong coding rule (which is probably not enforced in GCC today). The documentation can
(and should) be generated (à la doxygen), which translates that requirement that only
API defined by structured comments understood by doxygen can be used outside of a module

> >
> > I'm sorry to say that, but current GCC (ie 4.7 or today's trunk) is *not* modular.
> 
> Modularity is not a binary quality, so this is not a helpful statement

IMHO modularity is an all or nothing quality. Our terminology differs!

> 
> > Don't
> > feel injured by that fact. Indeed, GCC is a little less messy than it was a few years
> > ago, but being less messy is not being modular IMHO. And something cannot be
> > "half-modular".
> 
> Absolutely it can, parts of the system can be arranged nicely into 
> modules, and parts of the system may not be.
> 
> > So I would be delighted if GCC was made of modules. But I have no idea of how that can be
> > done.
> 
> Then your comments are not at all helpful, since they just
> reflect vague goals which everyone agrees on.

No, I was expressing the wish that qualified people having a global understanding of GCC
(which I have not) would propose a well defined and small set of modules

> 
> > I do believe that identifiers in GCC should be organized in such a way that the module
> > they belong to is visible at once. I think that a prefix (à la GTK) or a C++ namespace
> > should be great. In particular, this means that most GCC identifiers should change
> > (which means that any such evolution is not syntactically gradual; it has to be made by
> > huge, but "easy", patches).
> 
> I am of the opinion that this would severely damage readability, it's 
> the same sort of thing that leads people in Ada to avoid use clauses
> completely.

I have absolutely no idea if the Ada parts of GCC can be made of several modules or not

> 
> Since in any decent IDE it's just a single click to find out where a 
> variable is declared, it's just noise to include this information in
> every variable name. Of course global variables with wide visibility
> should have appropriate names, but the idea that all identifiers
> should be prefixed is horrible IMO

Namespaces in C++ gives you exactly that. If we go the C++ route, why should we not use
namespaces for modules? If we stay in C, then we can have prefixes, and GTK experience
shows that it is helpful and not horrible (any decent editor has good completion),
contrarily to your claim (of course I am speaking only of exported identifiers, usable
from other modules). When you code in Gtk in C you know at a glance to which module a
given public identifier belongs (and in which source files you can find its
implementation). This helps a lot.

Regards.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: GCC 5 & modularity

[Jonathan Wakely]

On 18 March 2012 16:56, Basile Starynkevitch wrote:
>
>   * a garbage collector. Even a modular GCC need some memory management policy (and
> ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO inside a compiler
> because a compiler has much more complex and circular data structures, and much less
> hierarchically organized, that a graphical tookit has).

As has been pointed out to you before, shared_ptr is designed to be
useful even with circular structures. Please read about weak_ptr.

Re: GCC 5 & modularity

[Basile Starynkevitch]

On Sun, 18 Mar 2012 20:49:24 +0000
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> On 18 March 2012 16:56, Basile Starynkevitch wrote:
> >
> >   * a garbage collector. Even a modular GCC need some memory management policy (and
> > ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO inside a compiler
> > because a compiler has much more complex and circular data structures, and much less
> > hierarchically organized, that a graphical tookit has).
> 
> As has been pointed out to you before, shared_ptr is designed to be
> useful even with circular structures. Please read about weak_ptr.


Then why has it not being used before?


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hi,

Gabriel Dos Reis <gdr@integrable-solutions.net> skribis:

> On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès
> <ludovic.courtes@inria.fr> wrote:

[...]

>> 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.
>
> Does not compute.  If you are using nested functions, you are not
> interested in C interoperability in the first place.

Sorry, I meant GNU C.

Ludo’.

Re: GCC 5 & modularity

[Jonathan Wakely]

On Mar 19, 2012 5:56 AM, "Basile Starynkevitch" wrote:
>
> On Sun, 18 Mar 2012 20:49:24 +0000
> Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> > On 18 March 2012 16:56, Basile Starynkevitch wrote:
> > >
> > >   * a garbage collector. Even a modular GCC need some memory management policy (and
> > > ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO inside a compiler
> > > because a compiler has much more complex and circular data structures, and much less
> > > hierarchically organized, that a graphical tookit has).
> >
> > As has been pointed out to you before, shared_ptr is designed to be
> > useful even with circular structures. Please read about weak_ptr.
>
>
> Then why has it not being used before?

I don't understand the question.  Are you asking why shared_ptr hasn't
been used in GCC before?  Surely that's obvious, the GCC code is still
written in C and no C++ templates have been introduced to the code
yet.

Maybe shared_ptr isn't the right tool for memory management in GCC,
but if it's rejected then I hope it will be for valid reasons, not
because of misinformation about being unsuitable for code with
circular references.

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Richard Guenther]

On Fri, Mar 16, 2012 at 6:19 PM, David Malcolm <dmalcolm@redhat.com> wrote:

> It seems that GCC has provided an API for registering plugins, but no
> API for the plugins to then actually use...  Perhaps the C++ move would
> be alleviated by having an actually C API for plugins to use?  I started
> writing a possible API for plugins, the idea being to port my python
> plugin to this as a middle layer, but it strikes me that this could also
> be used for the embedding case as well.  So perhaps the first step might
> be to implement the plugin API, and that could evolve into the
> inter-library API that the different parts of a more modular GCC could
> use to talk to each other?
>
> The proposed API might look like this:
>
> /*
>  Pure C for maximum compatibility
>  All macros begin with a "GCC_" prefix
>  All symbols begin with a "gcc_" prefix with _ separators, though I
>  happen to prefer the CPython style (e.g. "GccBasicBlock_GetIndex");
>  bikeshed away!
>  (You may only call such a symbol when you have the Big GCC Lock?)
>  All types begin with a "gcc_" prefix (again, I'd prefer CPython style
>  e.g. "struct GccBasicBlock").
>  How acceptable is it to autogenerate parts of the API? (this is what
>  I do in my python plugin; naturally I use python for this).
> */
>
> /* Compatibility macros: */
> #define GCC_API(RETURN_TYPE) extern RETURN_TYPE
>
> /* All types are opaque; internally these might simply embed one of
> gcc's real types as its single field; integration with GC could be
> interesting though: */
> typedef struct gcc_cfg gcc_cfg;
> typedef struct gcc_basic_block gcc_basic_block;
> typedef struct gcc_edge gcc_edge;
>
> /* Declarations: control flow graphs */
>
> /* gcc_cfg: */
> GCC_API(gcc_basic_block *)
> gcc_cfg_get_entry(gcc_cfg *cfg);
>
> GCC_API(gcc_basic_block *)
> gcc_cfg_get_exit(gcc_cfg *cfg);
>
> /* gcc_basic_block: */
> GCC_API(int)
> gcc_basic_block_get_index(const gcc_basic_block *bb);
>
> /* gcc_edge: */
> GCC_API(gcc_basic_block *)
> gcc_edge_get_src(gcc_edge *e);
>
> GCC_API(gcc_basic_block *)
> gcc_edge_get_dest(gcc_edge *e);
>
> /* ...etc... */
>

Yes, I think we desperately need something like the above.  And I was
strongly against our current "plugin API" because of all the reasons
you cite.  But it seems that the people driving plugins meant that plugins
should be able to do everything an embedded GCC pass can do.

I think an API like you propose with clear direction towards

 1) providing simple and forward-compatible ways of, first of all
     _introspection_ (to make static analyses possible)
 2) and _instrumentation_ (to make dynamic analyses possible)

and not for implementing everything that GCC can (that will be never
forward/backward compatible).  The above should eventually be
possible on the different IL kinds GCC has, but first and foremost
targeting plain GIMPLE (+ SSA) plus the CFG and the CGRAPH
parts should be enough.

Providing python/guile/whatever bindings for such simple(!) C plugin API
should then eventually embedded into GCC itself.

But no, I'm not volunteering (I'm volunteering to do the review work).
The above has the same issue as the "we-want-to-be-more-like-LLVM"
stuff - it lacks the people to actually implement it, and GCC at its
present state still has to evolve, we can't and do not want to just spend
a complete release or two with just turning GCC upside-down.

Richard.

Re: GCC 4.7.0RC: Mangled names in cc1

[Gabriel Dos Reis]

On Mon, Mar 19, 2012 at 4:57 AM, Ludovic Courtès
<ludovic.courtes@inria.fr> wrote:
> Hi,
>
> Gabriel Dos Reis <gdr@integrable-solutions.net> skribis:
>
>> On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès
>> <ludovic.courtes@inria.fr> wrote:
>
> [...]
>
>>> 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.
>>
>> Does not compute.  If you are using nested functions, you are not
>> interested in C interoperability in the first place.
>
> Sorry, I meant GNU C.

Interoperability is a two-way street; it means you have to live in
the intersection understood by both languages.

-- Gaby

Re: GCC 5 & modularity

[Gabriel Dos Reis]

On Mon, Mar 19, 2012 at 12:56 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Sun, 18 Mar 2012 20:49:24 +0000
> Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
>> On 18 March 2012 16:56, Basile Starynkevitch wrote:
>> >
>> >   * a garbage collector. Even a modular GCC need some memory management policy (and
>> > ref-counting à la GTK, or à la std::shared_ptr is not enough IMHO inside a compiler
>> > because a compiler has much more complex and circular data structures, and much less
>> > hierarchically organized, that a graphical tookit has).
>>
>> As has been pointed out to you before, shared_ptr is designed to be
>> useful even with circular structures. Please read about weak_ptr.
>
>
> Then why has it not being used before?

by whom? where?

-- Gaby

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Ludovic Courtès]

Hi,

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

> But no, I'm not volunteering (I'm volunteering to do the review work).
> The above has the same issue as the "we-want-to-be-more-like-LLVM"
> stuff - it lacks the people to actually implement it, and GCC at its
> present state still has to evolve, we can't and do not want to just spend
> a complete release or two with just turning GCC upside-down.

What David proposes looks great, but also fairly intrusive and
development-intensive.

Perhaps a more incremental approach could be taken.  For instance, I
would argue that changes to the tree and GIMPLE APIs could be made
conservatively, on the grounds that they are most likely used by
plug-ins out there.  IOW, rather than a commitment to a stable API,
which would hinder the work of GCC developers, this would be an informal
agreement to not make the plug-in developers life too hard.

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.

In the longer term, providing a GCC plug-in alongside one’s library or
program should become as natural as providing a syntax highlighting mode.

Thanks,
Ludo’.

Re: GCC 4.7.0RC: Mangled names in cc1

[Ludovic Courtès]

Hello,

For the interested reader, I eventually solved the nested function issue
by using either nested functions or C++11 lambdas, depending on whether
g++ is being used [0].

This is abstracted away by these (surprisingly not-too-ugly) macros to
define a local function, and declare a function parameter:

  #ifdef __cplusplus

  /* G++ doesn't implement nested functions, so use C++11 lambdas instead.  */

  # include <functional>

  # define local_define(ret, name, parms)     auto name = [=]parms
  # define function_parm(ret, name, parms)    std::function<ret parms> name

  #else  /* !__cplusplus */

  /* GNU C nested functions.  */

  # define local_define(ret, name, parms)     ret name parms
  # define function_parm(ret, name, parms)    ret (*name) parms

  #endif /* !__cplusplus */

They are used like this:

  static tree
  map (function_parm (tree, func, (const_tree)), tree t)
  {
    [...]
  }

  static tree
  foo (tree lst, tree y)
  {
    local_define (tree, frob, (const_tree x))
    {
      return do_something (x, y);
    };

    return map (frob, lst);
  }

Then there were other subtleties to work around, such as the lack of
support for designated initializers in g++.

Thanks,
Ludo’.

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

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Richard Guenther]

2012/3/19 Ludovic Courtès <ludovic.courtes@inria.fr>:
> Hi,
>
> Richard Guenther <richard.guenther@gmail.com> skribis:
>
>> But no, I'm not volunteering (I'm volunteering to do the review work).
>> The above has the same issue as the "we-want-to-be-more-like-LLVM"
>> stuff - it lacks the people to actually implement it, and GCC at its
>> present state still has to evolve, we can't and do not want to just spend
>> a complete release or two with just turning GCC upside-down.
>
> What David proposes looks great, but also fairly intrusive and
> development-intensive.
>
> Perhaps a more incremental approach could be taken.  For instance, I
> would argue that changes to the tree and GIMPLE APIs could be made
> conservatively, on the grounds that they are most likely used by
> plug-ins out there.  IOW, rather than a commitment to a stable API,
> which would hinder the work of GCC developers, this would be an informal
> agreement to not make the plug-in developers life too hard.
>
> 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.  And exactly the problem.  There
will be never even API compatibility between major releases of GCC
with the current plugin "API".

Richard.

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Gabriel Dos Reis]

On Mon, Mar 19, 2012 at 10:36 AM, Ludovic Courtès
<ludovic.courtes@inria.fr> wrote:

> Perhaps a more incremental approach could be taken.  For instance, I
> would argue that changes to the tree and GIMPLE APIs could be made
> conservatively, on the grounds that they are most likely used by
> plug-ins out there.

Hmm, this is exactly the argument that people objected to
back in the days when there were talks of plug-ins.  The
existence of plugins should not be a hindrance on evolving
GCC internals.

> IOW, rather than a commitment to a stable API,
> which would hinder the work of GCC developers, this would be an informal
> agreement to not make the plug-in developers life too hard.

-- Gaby

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Ludovic Courtès]

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.

Thanks,
Ludo’.

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

Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1)

[Richard Guenther]

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