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

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

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

Hi Richard, Richard Guenther skribis: > 2012/3/19 Ludovic Courtès : [...] >> In the example of name mangling, I’d just have wrapped in ‘extern "C"’ >> all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in.  The >> rationale is that it simplifies plug-in maintenance, while not impeding

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

On Mon, Mar 19, 2012 at 10:36 AM, Ludovic Courtès 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

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

2012/3/19 Ludovic Courtès : > Hi, > > Richard Guenther 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

Re: GCC 4.7.0RC: Mangled names in cc1

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 par

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

Hi, Richard Guenther 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

Re: GCC 4.7.0RC: Mangled names in cc1

On Mon, Mar 19, 2012 at 4:57 AM, Ludovic Courtès wrote: > Hi, > > Gabriel Dos Reis skribis: > >> On Fri, Mar 16, 2012 at 8:04 AM, 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 co

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

On Fri, Mar 16, 2012 at 6:19 PM, David Malcolm 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 A

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Gabriel Dos Reis skribis: > On Fri, Mar 16, 2012 at 8:04 AM, 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. > > Does not compute. If you

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

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 a

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

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 . Many of your ideas seem potentially useful additions to

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

On Fri, Mar 16, 2012 at 12:19 PM, David Malcolm 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

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

On Fri, Mar 16, 2012 at 13:19, David Malcolm 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 w

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

On Fri, 2012-03-16 at 16:17 +0100, Ludovic Courtès wrote: > Hello, > > Richard Guenther skribis: > > > 2012/3/16 Ludovic Courtès : > > [...] > > > 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 intern

Re: GCC 4.7.0RC: Mangled names in cc1

On Fri, Mar 16, 2012 at 8:04 AM, Ludovic Courtès 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

Re: GCC 4.7.0RC: Mangled names in cc1

On Fri, Mar 16, 2012 at 6:03 AM, Ludovic Courtès 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

Re: GCC 4.7.0RC: Mangled names in cc1

Hello, Richard Guenther skribis: > 2012/3/16 Ludovic Courtès : [...] > 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 s

Re: GCC 4.7.0RC: Mangled names in cc1

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

Re: GCC 4.7.0RC: Mangled names in cc1

2012/3/16 Ludovic Courtès : > Hi, > > Richard Guenther skribis: > >> 2012/3/16 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 suppo

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Richard Guenther skribis: > 2012/3/16 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 ho

Re: GCC 4.7.0RC: Mangled names in cc1

2012/3/16 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? Don't use nested funct

Re: GCC 4.7.0RC: Mangled names in cc1

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

Re: GCC 4.7.0RC: Mangled names in cc1

On Mon, Mar 12, 2012 at 7:10 AM, Richard Guenther wrote: >> In 4.7, finding out whether gcc or g++ should be used is left as an >> exercise to the plug-in writer, which is inconvenient at best. > > Well, that is what you get for having plugins without a proper plugin API ;) > It's not going to ch

Re: GCC 4.7.0RC: Mangled names in cc1

On Mon, Mar 12, 2012 at 3:56 AM, Ludovic Courtès wrote: > Symbols declared in are mangled, for instance.  I’m not sure > whether 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

2012/3/12 Ludovic Courtès : > Hi, > > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> Ian Lance Taylor skribis: >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> Ian Lance Taylor skribis: >> >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>> Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> However, thi

Re: GCC 4.7.0RC: Mangled names in cc1

On Fri, 2012-03-09 at 11:41 +0100, Ludovic Courtès wrote: > Hi, > > Andrew Pinski skribis: > > > 2012/3/9 Ludovic Courtès : > > > >> 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

Re: GCC 4.7.0RC: Mangled names in cc1

ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> Ian Lance Taylor skribis: >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: > However, this means that plug-ins must now be built with

Re: GCC 4.7.0RC: Mangled names in cc1

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

Re: GCC 4.7.0RC: Mangled names in cc1

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

Re: GCC 4.7.0RC: Mangled names in cc1

Ian Lance Taylor skribis: > ludovic.cour...@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

Re: GCC 4.7.0RC: Mangled names in cc1

ludovic.cour...@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 transiti

Re: GCC 4.7.0RC: Mangled names in cc1

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 w

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, ludovic.cour...@inria.fr (Ludovic Courtès) skribis: > Andrew Pinski skribis: > >> 2012/3/9 Ludovic Courtès : >> >>> 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 the

Re: GCC 4.7.0RC: Mangled names in cc1

Hi, Andrew Pinski skribis: > 2012/3/9 Ludovic Courtès : > >> 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,

Re: GCC 4.7.0RC: Mangled names in cc1

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

Re: GCC 4.7.0RC: Mangled names in cc1

2012/3/9 Ludovic Courtès : > 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 Pinsk

GCC 4.7.0RC: Mangled names in cc1

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 00640a00 gDF .text 007a Base _Z20fold_build1_stat_locj9tree_codeP9tree_nodeS1_ Indeed,