* GCC 4.7.0RC: Mangled names in cc1 @ 2012-03-09 9:51 Ludovic Courtès 2012-03-09 9:54 ` Andrew Pinski 0 siblings, 1 reply; 45+ messages in thread From: Ludovic Courtès @ 2012-03-09 9:51 UTC (permalink / raw) To: gcc 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>. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 9:51 GCC 4.7.0RC: Mangled names in cc1 Ludovic Courtès @ 2012-03-09 9:54 ` Andrew Pinski 2012-03-09 10:00 ` Jakub Jelinek 2012-03-09 10:41 ` Ludovic Courtès 0 siblings, 2 replies; 45+ messages in thread From: Andrew Pinski @ 2012-03-09 9:54 UTC (permalink / raw) To: Ludovic Courtès; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 9:54 ` Andrew Pinski @ 2012-03-09 10:00 ` Jakub Jelinek 2012-03-09 10:41 ` Ludovic Courtès 1 sibling, 0 replies; 45+ messages in thread From: Jakub Jelinek @ 2012-03-09 10:00 UTC (permalink / raw) To: Ludovic Courtès; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 9:54 ` Andrew Pinski 2012-03-09 10:00 ` Jakub Jelinek @ 2012-03-09 10:41 ` Ludovic Courtès 2012-03-09 13:26 ` Ludovic Courtès ` (2 more replies) 1 sibling, 3 replies; 45+ messages in thread From: Ludovic Courtès @ 2012-03-09 10:41 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc 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’. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 10:41 ` Ludovic Courtès @ 2012-03-09 13:26 ` Ludovic Courtès 2012-03-09 14:17 ` Duncan Sands 2012-03-09 14:57 ` Ian Lance Taylor 2012-03-10 1:25 ` David Malcolm 2 siblings, 1 reply; 45+ messages in thread From: Ludovic Courtès @ 2012-03-09 13:26 UTC (permalink / raw) To: gcc [-- 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â. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 13:26 ` Ludovic Courtès @ 2012-03-09 14:17 ` Duncan Sands 0 siblings, 0 replies; 45+ messages in thread From: Duncan Sands @ 2012-03-09 14:17 UTC (permalink / raw) To: gcc 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 10:41 ` Ludovic Courtès 2012-03-09 13:26 ` Ludovic Courtès @ 2012-03-09 14:57 ` Ian Lance Taylor 2012-03-09 15:42 ` Ludovic Courtès 2012-03-10 1:25 ` David Malcolm 2 siblings, 1 reply; 45+ messages in thread From: Ian Lance Taylor @ 2012-03-09 14:57 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 14:57 ` Ian Lance Taylor @ 2012-03-09 15:42 ` Ludovic Courtès 2012-03-09 16:01 ` Ian Lance Taylor 0 siblings, 1 reply; 45+ messages in thread From: Ludovic Courtès @ 2012-03-09 15:42 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Andrew Pinski, gcc 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’. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 15:42 ` Ludovic Courtès @ 2012-03-09 16:01 ` Ian Lance Taylor 2012-03-09 17:00 ` Ludovic Courtès 0 siblings, 1 reply; 45+ messages in thread From: Ian Lance Taylor @ 2012-03-09 16:01 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 16:01 ` Ian Lance Taylor @ 2012-03-09 17:00 ` Ludovic Courtès 2012-03-09 18:08 ` Ian Lance Taylor 0 siblings, 1 reply; 45+ messages in thread From: Ludovic Courtès @ 2012-03-09 17:00 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Andrew Pinski, gcc 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’. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 17:00 ` Ludovic Courtès @ 2012-03-09 18:08 ` Ian Lance Taylor 2012-03-12 8:56 ` Ludovic Courtès 0 siblings, 1 reply; 45+ messages in thread From: Ian Lance Taylor @ 2012-03-09 18:08 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 18:08 ` Ian Lance Taylor @ 2012-03-12 8:56 ` Ludovic Courtès 2012-03-12 12:11 ` Richard Guenther 2012-03-12 12:30 ` Gabriel Dos Reis 0 siblings, 2 replies; 45+ messages in thread From: Ludovic Courtès @ 2012-03-12 8:56 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Andrew Pinski, gcc 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’. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-12 8:56 ` Ludovic Courtès @ 2012-03-12 12:11 ` Richard Guenther 2012-03-12 12:31 ` Gabriel Dos Reis 2012-03-16 11:04 ` Ludovic Courtès 2012-03-12 12:30 ` Gabriel Dos Reis 1 sibling, 2 replies; 45+ messages in thread From: Richard Guenther @ 2012-03-12 12:11 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Ian Lance Taylor, Andrew Pinski, gcc 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’. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-12 12:11 ` Richard Guenther @ 2012-03-12 12:31 ` Gabriel Dos Reis 2012-03-16 11:04 ` Ludovic Courtès 1 sibling, 0 replies; 45+ messages in thread From: Gabriel Dos Reis @ 2012-03-12 12:31 UTC (permalink / raw) To: Richard Guenther Cc: Ludovic Courtès, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-12 12:11 ` Richard Guenther 2012-03-12 12:31 ` Gabriel Dos Reis @ 2012-03-16 11:04 ` Ludovic Courtès 2012-03-16 11:05 ` Richard Guenther 2012-03-16 17:35 ` Gabriel Dos Reis 1 sibling, 2 replies; 45+ messages in thread From: Ludovic Courtès @ 2012-03-16 11:04 UTC (permalink / raw) To: Richard Guenther; +Cc: Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 11:04 ` Ludovic Courtès @ 2012-03-16 11:05 ` Richard Guenther 2012-03-16 13:04 ` Ludovic Courtès 2012-03-19 15:46 ` Ludovic Courtès 2012-03-16 17:35 ` Gabriel Dos Reis 1 sibling, 2 replies; 45+ messages in thread From: Richard Guenther @ 2012-03-16 11:05 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 11:05 ` Richard Guenther @ 2012-03-16 13:04 ` Ludovic Courtès 2012-03-16 13:08 ` Richard Guenther ` (2 more replies) 2012-03-19 15:46 ` Ludovic Courtès 1 sibling, 3 replies; 45+ messages in thread From: Ludovic Courtès @ 2012-03-16 13:04 UTC (permalink / raw) To: Richard Guenther; +Cc: Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 13:04 ` Ludovic Courtès @ 2012-03-16 13:08 ` Richard Guenther 2012-03-16 15:17 ` Ludovic Courtès 2012-03-16 13:24 ` GCC 4.7.0RC: Mangled names in cc1 Basile Starynkevitch 2012-03-16 17:40 ` Gabriel Dos Reis 2 siblings, 1 reply; 45+ messages in thread From: Richard Guenther @ 2012-03-16 13:08 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 13:08 ` Richard Guenther @ 2012-03-16 15:17 ` Ludovic Courtès 2012-03-16 18:48 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) David Malcolm 0 siblings, 1 reply; 45+ messages in thread From: Ludovic Courtès @ 2012-03-16 15:17 UTC (permalink / raw) To: Richard Guenther; +Cc: Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-16 15:17 ` Ludovic Courtès @ 2012-03-16 18:48 ` David Malcolm 2012-03-16 19:03 ` Diego Novillo ` (4 more replies) 0 siblings, 5 replies; 45+ messages in thread From: David Malcolm @ 2012-03-16 18:48 UTC (permalink / raw) To: Ludovic Courtès Cc: Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-16 18:48 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) David Malcolm @ 2012-03-16 19:03 ` Diego Novillo 2012-03-16 19:29 ` Gabriel Dos Reis ` (3 subsequent siblings) 4 siblings, 0 replies; 45+ messages in thread From: Diego Novillo @ 2012-03-16 19:03 UTC (permalink / raw) To: David Malcolm Cc: Ludovic Courtès, Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-16 18:48 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) David Malcolm 2012-03-16 19:03 ` Diego Novillo @ 2012-03-16 19:29 ` Gabriel Dos Reis 2012-03-16 19:42 ` Joseph S. Myers ` (2 subsequent siblings) 4 siblings, 0 replies; 45+ messages in thread From: Gabriel Dos Reis @ 2012-03-16 19:29 UTC (permalink / raw) To: David Malcolm Cc: Ludovic Courtès, Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-16 18:48 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) David Malcolm 2012-03-16 19:03 ` Diego Novillo 2012-03-16 19:29 ` Gabriel Dos Reis @ 2012-03-16 19:42 ` Joseph S. Myers 2012-03-18 16:56 ` GCC 5 & modularity Basile Starynkevitch 2012-03-16 20:22 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) Jonathan Wakely 2012-03-19 10:08 ` Richard Guenther 4 siblings, 1 reply; 45+ messages in thread From: Joseph S. Myers @ 2012-03-16 19:42 UTC (permalink / raw) To: David Malcolm Cc: Ludovic Courtès, Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* GCC 5 & modularity 2012-03-16 19:42 ` Joseph S. Myers @ 2012-03-18 16:56 ` Basile Starynkevitch 2012-03-18 17:11 ` Robert Dewar 2012-03-18 20:49 ` Jonathan Wakely 0 siblings, 2 replies; 45+ messages in thread From: Basile Starynkevitch @ 2012-03-18 16:56 UTC (permalink / raw) To: Joseph S. Myers, dnovillo; +Cc: gcc 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} *** ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5 & modularity 2012-03-18 16:56 ` GCC 5 & modularity Basile Starynkevitch @ 2012-03-18 17:11 ` Robert Dewar 2012-03-18 17:53 ` Basile Starynkevitch 2012-03-18 20:49 ` Jonathan Wakely 1 sibling, 1 reply; 45+ messages in thread From: Robert Dewar @ 2012-03-18 17:11 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Joseph S. Myers, dnovillo, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5 & modularity 2012-03-18 17:11 ` Robert Dewar @ 2012-03-18 17:53 ` Basile Starynkevitch 0 siblings, 0 replies; 45+ messages in thread From: Basile Starynkevitch @ 2012-03-18 17:53 UTC (permalink / raw) To: Robert Dewar; +Cc: Joseph S. Myers, dnovillo, gcc 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} *** ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5 & modularity 2012-03-18 16:56 ` GCC 5 & modularity Basile Starynkevitch 2012-03-18 17:11 ` Robert Dewar @ 2012-03-18 20:49 ` Jonathan Wakely 2012-03-19 5:57 ` Basile Starynkevitch 1 sibling, 1 reply; 45+ messages in thread From: Jonathan Wakely @ 2012-03-18 20:49 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Joseph S. Myers, dnovillo, gcc 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5 & modularity 2012-03-18 20:49 ` Jonathan Wakely @ 2012-03-19 5:57 ` Basile Starynkevitch 2012-03-19 10:04 ` Jonathan Wakely 2012-03-19 10:57 ` Gabriel Dos Reis 0 siblings, 2 replies; 45+ messages in thread From: Basile Starynkevitch @ 2012-03-19 5:57 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Joseph S. Myers, dnovillo, gcc 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} *** ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5 & modularity 2012-03-19 5:57 ` Basile Starynkevitch @ 2012-03-19 10:04 ` Jonathan Wakely 2012-03-19 10:57 ` Gabriel Dos Reis 1 sibling, 0 replies; 45+ messages in thread From: Jonathan Wakely @ 2012-03-19 10:04 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc, Joseph S. Myers, dnovillo 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5 & modularity 2012-03-19 5:57 ` Basile Starynkevitch 2012-03-19 10:04 ` Jonathan Wakely @ 2012-03-19 10:57 ` Gabriel Dos Reis 1 sibling, 0 replies; 45+ messages in thread From: Gabriel Dos Reis @ 2012-03-19 10:57 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Jonathan Wakely, Joseph S. Myers, dnovillo, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-16 18:48 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) David Malcolm ` (2 preceding siblings ...) 2012-03-16 19:42 ` Joseph S. Myers @ 2012-03-16 20:22 ` Jonathan Wakely 2012-03-19 10:08 ` Richard Guenther 4 siblings, 0 replies; 45+ messages in thread From: Jonathan Wakely @ 2012-03-16 20:22 UTC (permalink / raw) To: David Malcolm Cc: Ludovic Courtès, Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-16 18:48 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) David Malcolm ` (3 preceding siblings ...) 2012-03-16 20:22 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) Jonathan Wakely @ 2012-03-19 10:08 ` Richard Guenther 2012-03-19 15:37 ` Ludovic Courtès 4 siblings, 1 reply; 45+ messages in thread From: Richard Guenther @ 2012-03-19 10:08 UTC (permalink / raw) To: David Malcolm; +Cc: Ludovic Courtès, Ian Lance Taylor, Andrew Pinski, gcc 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-19 10:08 ` Richard Guenther @ 2012-03-19 15:37 ` Ludovic Courtès 2012-03-19 15:58 ` Richard Guenther 2012-03-19 18:04 ` Gabriel Dos Reis 0 siblings, 2 replies; 45+ messages in thread From: Ludovic Courtès @ 2012-03-19 15:37 UTC (permalink / raw) To: Richard Guenther; +Cc: David Malcolm, Ian Lance Taylor, Andrew Pinski, gcc 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’. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-19 15:37 ` Ludovic Courtès @ 2012-03-19 15:58 ` Richard Guenther 2012-03-20 11:47 ` Ludovic Courtès 2012-03-19 18:04 ` Gabriel Dos Reis 1 sibling, 1 reply; 45+ messages in thread From: Richard Guenther @ 2012-03-19 15:58 UTC (permalink / raw) To: Ludovic Courtès; +Cc: David Malcolm, Ian Lance Taylor, Andrew Pinski, gcc 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-19 15:58 ` Richard Guenther @ 2012-03-20 11:47 ` Ludovic Courtès 2012-03-20 12:07 ` Richard Guenther 0 siblings, 1 reply; 45+ messages in thread From: Ludovic Courtès @ 2012-03-20 11:47 UTC (permalink / raw) To: Richard Guenther; +Cc: David Malcolm, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-20 11:47 ` Ludovic Courtès @ 2012-03-20 12:07 ` Richard Guenther 0 siblings, 0 replies; 45+ messages in thread From: Richard Guenther @ 2012-03-20 12:07 UTC (permalink / raw) To: Ludovic Courtès; +Cc: David Malcolm, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 2012-03-19 15:37 ` Ludovic Courtès 2012-03-19 15:58 ` Richard Guenther @ 2012-03-19 18:04 ` Gabriel Dos Reis 1 sibling, 0 replies; 45+ messages in thread From: Gabriel Dos Reis @ 2012-03-19 18:04 UTC (permalink / raw) To: Ludovic Courtès Cc: Richard Guenther, David Malcolm, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 13:04 ` Ludovic Courtès 2012-03-16 13:08 ` Richard Guenther @ 2012-03-16 13:24 ` Basile Starynkevitch 2012-03-16 17:40 ` Gabriel Dos Reis 2 siblings, 0 replies; 45+ messages in thread From: Basile Starynkevitch @ 2012-03-16 13:24 UTC (permalink / raw) To: Ludovic Courtès; +Cc: gcc 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} *** ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 13:04 ` Ludovic Courtès 2012-03-16 13:08 ` Richard Guenther 2012-03-16 13:24 ` GCC 4.7.0RC: Mangled names in cc1 Basile Starynkevitch @ 2012-03-16 17:40 ` Gabriel Dos Reis 2012-03-19 9:57 ` Ludovic Courtès 2 siblings, 1 reply; 45+ messages in thread From: Gabriel Dos Reis @ 2012-03-16 17:40 UTC (permalink / raw) To: Ludovic Courtès Cc: Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 17:40 ` Gabriel Dos Reis @ 2012-03-19 9:57 ` Ludovic Courtès 2012-03-19 10:54 ` Gabriel Dos Reis 0 siblings, 1 reply; 45+ messages in thread From: Ludovic Courtès @ 2012-03-19 9:57 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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’. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-19 9:57 ` Ludovic Courtès @ 2012-03-19 10:54 ` Gabriel Dos Reis 0 siblings, 0 replies; 45+ messages in thread From: Gabriel Dos Reis @ 2012-03-19 10:54 UTC (permalink / raw) To: Ludovic Courtès Cc: Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 11:05 ` Richard Guenther 2012-03-16 13:04 ` Ludovic Courtès @ 2012-03-19 15:46 ` Ludovic Courtès 1 sibling, 0 replies; 45+ messages in thread From: Ludovic Courtès @ 2012-03-19 15:46 UTC (permalink / raw) To: Richard Guenther; +Cc: Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-16 11:04 ` Ludovic Courtès 2012-03-16 11:05 ` Richard Guenther @ 2012-03-16 17:35 ` Gabriel Dos Reis 1 sibling, 0 replies; 45+ messages in thread From: Gabriel Dos Reis @ 2012-03-16 17:35 UTC (permalink / raw) To: Ludovic Courtès Cc: Richard Guenther, Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-12 8:56 ` Ludovic Courtès 2012-03-12 12:11 ` Richard Guenther @ 2012-03-12 12:30 ` Gabriel Dos Reis 1 sibling, 0 replies; 45+ messages in thread From: Gabriel Dos Reis @ 2012-03-12 12:30 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Ian Lance Taylor, Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: GCC 4.7.0RC: Mangled names in cc1 2012-03-09 10:41 ` Ludovic Courtès 2012-03-09 13:26 ` Ludovic Courtès 2012-03-09 14:57 ` Ian Lance Taylor @ 2012-03-10 1:25 ` David Malcolm 2 siblings, 0 replies; 45+ messages in thread From: David Malcolm @ 2012-03-10 1:25 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Andrew Pinski, gcc 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2012-03-20 12:07 UTC | newest] Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-09 9:51 GCC 4.7.0RC: Mangled names in cc1 Ludovic Courtès 2012-03-09 9:54 ` Andrew Pinski 2012-03-09 10:00 ` Jakub Jelinek 2012-03-09 10:41 ` Ludovic Courtès 2012-03-09 13:26 ` Ludovic Courtès 2012-03-09 14:17 ` Duncan Sands 2012-03-09 14:57 ` Ian Lance Taylor 2012-03-09 15:42 ` Ludovic Courtès 2012-03-09 16:01 ` Ian Lance Taylor 2012-03-09 17:00 ` Ludovic Courtès 2012-03-09 18:08 ` Ian Lance Taylor 2012-03-12 8:56 ` Ludovic Courtès 2012-03-12 12:11 ` Richard Guenther 2012-03-12 12:31 ` Gabriel Dos Reis 2012-03-16 11:04 ` Ludovic Courtès 2012-03-16 11:05 ` Richard Guenther 2012-03-16 13:04 ` Ludovic Courtès 2012-03-16 13:08 ` Richard Guenther 2012-03-16 15:17 ` Ludovic Courtès 2012-03-16 18:48 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) David Malcolm 2012-03-16 19:03 ` Diego Novillo 2012-03-16 19:29 ` Gabriel Dos Reis 2012-03-16 19:42 ` Joseph S. Myers 2012-03-18 16:56 ` GCC 5 & modularity Basile Starynkevitch 2012-03-18 17:11 ` Robert Dewar 2012-03-18 17:53 ` Basile Starynkevitch 2012-03-18 20:49 ` Jonathan Wakely 2012-03-19 5:57 ` Basile Starynkevitch 2012-03-19 10:04 ` Jonathan Wakely 2012-03-19 10:57 ` Gabriel Dos Reis 2012-03-16 20:22 ` GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) Jonathan Wakely 2012-03-19 10:08 ` Richard Guenther 2012-03-19 15:37 ` Ludovic Courtès 2012-03-19 15:58 ` Richard Guenther 2012-03-20 11:47 ` Ludovic Courtès 2012-03-20 12:07 ` Richard Guenther 2012-03-19 18:04 ` Gabriel Dos Reis 2012-03-16 13:24 ` GCC 4.7.0RC: Mangled names in cc1 Basile Starynkevitch 2012-03-16 17:40 ` Gabriel Dos Reis 2012-03-19 9:57 ` Ludovic Courtès 2012-03-19 10:54 ` Gabriel Dos Reis 2012-03-19 15:46 ` Ludovic Courtès 2012-03-16 17:35 ` Gabriel Dos Reis 2012-03-12 12:30 ` Gabriel Dos Reis 2012-03-10 1:25 ` David Malcolm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).