Re: [RFC] Switching implementation language to C++
On Wed, 2 Jun 2010, Richard Guenther wrote: > I also notice that all cc1 binaries are dynamically linked against > libstdc++ - didn't we want to use -static-libstdc++ and link against > the libstdc++ we bootstrap? Yes, that is stated in Ian's slides. There are a series of related configure options --with-host-libstdcxx, --with-stage1-ldflags, --with-stage1-libs, --with-boot-ldflags, --with-boot-libs, which certainly allow you to do as you wish for cross compilers (you only need --with-host-libstdcxx there) and probably for other configurations, but maybe the defaults are currently wrong. There are at least three useful cases for native compilers (link statically, link dynamically, link dynamically with an RPATH using $ORIGIN); the last is probably the trickiest because of getting that $ through a series of levels of shell and make. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Switching implementation language to C++
On Mon, 31 May 2010, Basile Starynkevitch wrote: > I would even imagine that later, one could configure GCC to have only a > C++ front-end, but no more a C one. That probably would be unusual, > since many important applications which want to be compiled by GCC (I am > thinking of the Linux kernel) will continue to exist in C. But I would > believe that a future GCC with only a C++ frontend and without a C > frontend would be possible, and be able to bootstrap (i.e. make stage3), > which is not true today. IIRC, today's GCC (i.e. 4.5) cannot even be > configured to have a C++ front-end without having a C front-end. Do we > want to change that? I believe it would be a bad idea to change GCC's language-independent runtime libraries (libgcc etc.) and libraries for ObjC, Fortran etc. to use C++. As such, building the C compiler will continue to be required in order to build those libraries. (It should also continue to be possible to build a cross compiler that only supports C - using, of course, pre-installed build-x-build and build-x-host C++ compilers - rather than requiring C++ support to be built for the target; the requirement to build a C++ host-x-target compiler will only apply for native bootstrap.) -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Switching implementation language to C++
On Tue, Jun 1, 2010 at 6:32 PM, Vladimir Makarov wrote: > Richard Guenther wrote: >> >> On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther >> wrote: >> >>> >>> On Mon, May 31, 2010 at 6:22 PM, Diego Novillo >>> wrote: >>> Now that the SC and the FSF have agreed to this, we should decide whether we switch and how. So, I would like comments on the following questions: 1- Should we switch to C++? >>> >>> Yes. >>> >>> 2- What is the cost in terms of build time? >>> >>> I was trying to measure but --enable-build-with-cxx is broken at >>> the moment. >>> >> >> After fixing build locally I now have >> >> ../configure && /usr/bin/time make >> 9197.01user 367.66system 2:42:39elapsed 98%CPU (0avgtext+0avgdata >> 2846176maxresident)k >> 1664096inputs+22984320outputs (537major+193300027minor)pagefaults 0swaps >> >> ../configure --enable-stage1-languages=c,c++ && /usr/bin/time make >> 9954.58user 412.32system 2:55:20elapsed 98%CPU (0avgtext+0avgdata >> 2846160maxresident)k >> 1386568inputs+26276920outputs (511major+219861615minor)pagefaults 0swaps >> >> 8% for adding C++ to the set of languages bootstrapped >> >> ../configure --enable-build-with-cxx && /usr/bin/time make >> 10072.37user 426.85system 2:57:15elapsed 98%CPU (0avgtext+0avgdata >> 2847472maxresident)k >> 1408096inputs+22940928outputs (377major+223161175minor)pagefaults 0swaps >> >> 1.5% for using C++ to do the building. >> >> > > That is a really small increase for building time. > > I was interested more in how much g++ is slower gcc in -O2 mode. > > I've done such comparison for gcc & g++ compilation time on most GCC C files > (from gcc directory) and got in average 10% (when gcc/g++ of version 4.6 > were used) - 20% (when gcc/g++ of version 4.3 were used) more compiler time > when g++ is used. The used gcc/g++ compilers were build in release mode > and the used machine was Corei7. My testing was obviously dominated by building libjava so I have repeated the above test with just C and C++ which should hit the worst case. /space/rguenther/src/svn/trunk/configure --enable-languages=c,c++ 4533.03user 182.35system 1:19:36elapsed 98%CPU (0avgtext+0avgdata 1744064maxresident)k 354032inputs+11561160outputs (125major+97529278minor)pagefaults 0swaps /space/rguenther/src/svn/trunk/configure --enable-stage1-languages=c,c++ --enable-languages=c,c++ 5304.18user 228.37system 1:33:24elapsed 98%CPU (0avgtext+0avgdata 1744048maxresident)k 535560inputs+14853792outputs (128major+124069696minor)pagefaults 0swaps That's a 15% increase because we now bootstrap C++. /space/rguenther/src/svn/trunk/configure --enable-build-with-cxx --enable-languages=c,c++ 5366.71user 232.97system 1:34:48elapsed 98%CPU (0avgtext+0avgdata 2321968maxresident)k 675848inputs+11452440outputs (1852major+124962774minor)pagefaults 0swaps On top of that a 1.2% increase because we do so with a C++ compiler. The size of the cc1 binary is when built with the C compiler textdata bss dec hex filename 12050451 615264 670688 13336403 cb7f53 gcc/cc1 and when built with the C++ compiler it is textdata bss dec hex filename 12327963 40344 1245888 13614195 cfbc73 gcc/cc1 which translates to a 2.3% size increase for the text part. I also notice that all cc1 binaries are dynamically linked against libstdc++ - didn't we want to use -static-libstdc++ and link against the libstdc++ we bootstrap? Richard.
Re: [RFC] Switching implementation language to C++
Diego Novillo writes: > 4- Should we make the switch during the 4.6 stage 1? My suggestion: put something in one common file that requires C++, just to force the use of C++ compilers, but with a comment that says "If you can't build this file, comment out the following and file a bug report with the GCC developers." We need to make sure we can build what we have *now* with C++ before we start adding more C++-isms, and we need to make sure our user base can build too. Maybe have an #ifdef that lets you take it out, so we can periodically check for "builds with C" much like we're currently checking for "builds with C++". 4.6 should be "defaults to C++ compiler", and let 4.7 be the first "must use C++ compiler". I don't think we should go from "defaults to C compiler" to "requires C++ compiler" in one release.
Re: [RFC] Switching implementation language to C++
* Joern Rennecke wrote on Tue, Jun 01, 2010 at 09:11:03PM CEST: > Quoting Ralf Wildenhues: > >* Toon Moene wrote on Tue, Jun 01, 2010 at 08:36:53PM CEST: > >> > >> In file included from ../../gcc/libcpp/system.h:341, > >> from ../../gcc/libcpp/expr.c:21: > >>../../gcc/libcpp/../include/libiberty.h:106: error: new declaration > >>‘char* basename(const char*)’ > >>/usr/include/string.h:601: error: ambiguates old declaration ‘const > >>char* basename(const char*)’ > > > >I'm working on that currently (the Autoconf patch). > > That's PR bootstrap/42798. > The patch has been posted to the autoconf mailing list in Febuary: > http://lists.gnu.org/archive/html/autoconf/2010-02/msg00057.html > What we need is a patch review. Yes. I am working on test case, documentation update etc., based on your patch.
Re: [RFC] Switching implementation language to C++
Quoting Ralf Wildenhues : * Toon Moene wrote on Tue, Jun 01, 2010 at 08:36:53PM CEST: In file included from ../../gcc/libcpp/system.h:341, from ../../gcc/libcpp/expr.c:21: ../../gcc/libcpp/../include/libiberty.h:106: error: new declaration ‘char* basename(const char*)’ /usr/include/string.h:601: error: ambiguates old declaration ‘const char* basename(const char*)’ I'm working on that currently (the Autoconf patch). That's PR bootstrap/42798. The patch has been posted to the autoconf mailing list in Febuary: http://lists.gnu.org/archive/html/autoconf/2010-02/msg00057.html What we need is a patch review.
Re: [RFC] Switching implementation language to C++
* Toon Moene wrote on Tue, Jun 01, 2010 at 08:36:53PM CEST: > > In file included from ../../gcc/libcpp/system.h:341, > from ../../gcc/libcpp/expr.c:21: > ../../gcc/libcpp/../include/libiberty.h:106: error: new declaration > ‘char* basename(const char*)’ > /usr/include/string.h:601: error: ambiguates old declaration ‘const > char* basename(const char*)’ I'm working on that currently (the Autoconf patch).
Re: [RFC] Switching implementation language to C++
On 06/01/2010 08:02 PM, Diego Novillo wrote: On Tue, Jun 1, 2010 at 14:00, Toon Moene wrote: On 06/01/2010 06:07 PM, Richard Guenther wrote: After fixing build locally I now have Are you planning to commit the fixes - I don't mind being a guinea pig in this - I have been recompiling gcc/gfortran and rebuilding our weather forecasting code now for a few weeks (almost) daily. These changes are already in. Well, that was a quicky (revision 160116): In file included from ../../gcc/libcpp/system.h:341, from ../../gcc/libcpp/expr.c:21: ../../gcc/libcpp/../include/libiberty.h:106: error: new declaration ‘char* basename(const char*)’ /usr/include/string.h:601: error: ambiguates old declaration ‘const char* basename(const char*)’ This is my build command: cd ~/compilers/gcc && svn up && echo "`date -u` (revision `svnversion .`)" >> LAST_UPDATED && cd ../obj-t && rm -rf * && ../gcc/configure --enable-checking=release --prefix=/usr/snp --enable-gold --enable-plugins --disable-multilib --disable-nls --with-arch-64=native --with-tune-64=native --enable-languages=fortran,c++ --enable-build-with-cxx --disable-werror && make -j8 (--disable-werror is necessary because you can't build a recent snapshot of binutils/gold without it). Cheers, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: [RFC] Switching implementation language to C++
On Tue, Jun 1, 2010 at 14:00, Toon Moene wrote: > On 06/01/2010 06:07 PM, Richard Guenther wrote: > >> After fixing build locally I now have > > Are you planning to commit the fixes - I don't mind being a guinea pig in > this - I have been recompiling gcc/gfortran and rebuilding our weather > forecasting code now for a few weeks (almost) daily. > These changes are already in. Diego.
Re: [RFC] Switching implementation language to C++
On 06/01/2010 06:07 PM, Richard Guenther wrote: After fixing build locally I now have Are you planning to commit the fixes - I don't mind being a guinea pig in this - I have been recompiling gcc/gfortran and rebuilding our weather forecasting code now for a few weeks (almost) daily. I already use --enable-languages=fortran,c++ --enable-stage1-languages=c++ to be able to build gold, so changing the last option to --enable-build-with-cxx won't be much of a hassle. Cheers, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: [RFC] Switching implementation language to C++
Richard Guenther wrote: On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther wrote: On Mon, May 31, 2010 at 6:22 PM, Diego Novillo wrote: Now that the SC and the FSF have agreed to this, we should decide whether we switch and how. So, I would like comments on the following questions: 1- Should we switch to C++? Yes. 2- What is the cost in terms of build time? I was trying to measure but --enable-build-with-cxx is broken at the moment. After fixing build locally I now have ../configure && /usr/bin/time make 9197.01user 367.66system 2:42:39elapsed 98%CPU (0avgtext+0avgdata 2846176maxresident)k 1664096inputs+22984320outputs (537major+193300027minor)pagefaults 0swaps ../configure --enable-stage1-languages=c,c++ && /usr/bin/time make 9954.58user 412.32system 2:55:20elapsed 98%CPU (0avgtext+0avgdata 2846160maxresident)k 1386568inputs+26276920outputs (511major+219861615minor)pagefaults 0swaps 8% for adding C++ to the set of languages bootstrapped ../configure --enable-build-with-cxx && /usr/bin/time make 10072.37user 426.85system 2:57:15elapsed 98%CPU (0avgtext+0avgdata 2847472maxresident)k 1408096inputs+22940928outputs (377major+223161175minor)pagefaults 0swaps 1.5% for using C++ to do the building. That is a really small increase for building time. I was interested more in how much g++ is slower gcc in -O2 mode. I've done such comparison for gcc & g++ compilation time on most GCC C files (from gcc directory) and got in average 10% (when gcc/g++ of version 4.6 were used) - 20% (when gcc/g++ of version 4.3 were used) more compiler time when g++ is used. The used gcc/g++ compilers were build in release mode and the used machine was Corei7.
Re: [RFC] Switching implementation language to C++
On Tue, Jun 1, 2010 at 12:00 PM, Richard Guenther wrote: > On Mon, May 31, 2010 at 6:22 PM, Diego Novillo wrote: >> >> Now that the SC and the FSF have agreed to this, we should decide whether we >> switch and how. So, I would like comments on the following questions: >> >> 1- Should we switch to C++? > > Yes. > >> 2- What is the cost in terms of build time? > > I was trying to measure but --enable-build-with-cxx is broken at > the moment. After fixing build locally I now have ../configure && /usr/bin/time make 9197.01user 367.66system 2:42:39elapsed 98%CPU (0avgtext+0avgdata 2846176maxresident)k 1664096inputs+22984320outputs (537major+193300027minor)pagefaults 0swaps ../configure --enable-stage1-languages=c,c++ && /usr/bin/time make 9954.58user 412.32system 2:55:20elapsed 98%CPU (0avgtext+0avgdata 2846160maxresident)k 1386568inputs+26276920outputs (511major+219861615minor)pagefaults 0swaps 8% for adding C++ to the set of languages bootstrapped ../configure --enable-build-with-cxx && /usr/bin/time make 10072.37user 426.85system 2:57:15elapsed 98%CPU (0avgtext+0avgdata 2847472maxresident)k 1408096inputs+22940928outputs (377major+223161175minor)pagefaults 0swaps 1.5% for using C++ to do the building. The host compiler used was GCC 4.3.4 built with release checking. Richard.
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 6:22 PM, Diego Novillo wrote: > > Now that the SC and the FSF have agreed to this, we should decide whether we > switch and how. So, I would like comments on the following questions: > > 1- Should we switch to C++? Yes. > 2- What is the cost in terms of build time? I was trying to measure but --enable-build-with-cxx is broken at the moment. > 3- What coding guidelines should we use? > 4- Should we make the switch during the 4.6 stage 1? Number 3 is irrelevant for the moment. We definitely need to switch to --enable-build-with-cxx by default during stage 1, otherwise we should postpone the conversion to 4.7. Thus, we need volunteers to do that, not to bikeshed on #3 ;) Richard.
Re: [RFC] Switching implementation language to C++
Geert Bosch wrote: > If we're just going to get some new power tools for our workshop > and let people have at it, the lessons we'll learn might end up > being more about what not to do, rather than a show case of their > effective use. That's why we're not doing that. Instead, we're going to determine what subset of C++ we're comfortable using, and then we're going to let people propose ways of using that subset. Nobody's suggesting letting people run around using their favorite C++ features in random ways. This is a chicken-egg thing. We couldn't reasonably ask people to start proposing ways of using C++ without knowing that the SC would allow it to be used. Now we've got that approval, and now people can suggest uses. I've already implicitly suggested one, namely, using single inheritance to implement the tree data structures, thereby avoiding casts up and down the hierarchy. Including, for example, declaring a routine that's supposed to take a DECL as taking a tree_decl&, instead of just a tree *. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On May 31, 2010, at 14:25, Mark Mitchell wrote: > That doesn't necessarily mean that we have to use lots of C++ features > everywhere. We can use the C (almost) subset of C++ if we want to in > some places. As an example, if the Fortran folks want to use C in the > Fortran front-end, then -- except to the extent required by the common > interfaces, those files could read as if they were C code. But, I think > they'd still need to be compiled with a C++ compiler because they'll > probably pull in headers that use C++ constructs. I don't see why the implementation language of the front end should necessarily be tied to that of the back end. One of the benefits we should get from switching implementation language is a cleaner interface between the language-specific parts of the compiler and the shared back end files. For the Ada compiler, we've never found it a disadvantage to use Ada as implementation language, even though the back end is written in C. The hard parts of mapping Ada idioms to the intermediate languages used in the back end have never been related to the language used for implementing the front end or back end. If anything, the strict separation between front end and back end data structures has helped avoiding inadvertent reuse of representations for constructs with similar yet subtly different properties. Ideally, when having a full C++ definition of the back end interface, we can use straight type and function definitions, instead of webs of header files with macro definitions. Maybe, some day, we could even use Ada directly to interface with libbackend, eliminating the last remaining non-Ada code in the Ada front end. However, it seems backwards to decide wether we want to change implementation language before we even have an outline of a design for a new interface, or at least some agreement on design goals. If we do not have a path to rewriting tree.h and friends using C++ to raise the abstraction level and improve maintainability of GCC (while maintaining performance and avoiding overgeneralization and needless complexity), I am not sure the cost of moving to C++ will result in many gains. Once we're using C++, there will be a great temptation to use overly complex data structures that would have been inconceivable with C. The best defense against this is a clear design that, at least for the most significant data structures, specifies the interface that is going to be used. Here is where we decide how we're going to do memory management, where we need dynamic data structures, where we may need dispatching etc. If we're just going to get some new power tools for our workshop and let people have at it, the lessons we'll learn might end up being more about what not to do, rather than a show case of their effective use. In short, what we seem to be missing is a clear objective on what we want to accomplish by switching to C++ and how we'll reach those goals. Without that, switching might be ill considered and not in GCC's best interest in the long run. -Geert
Re: [RFC] Switching implementation language to C++
Basile Starynkevitch wrote: > You forgot to mention plugins. In my understanding, any future GCC > plugin would necessarily be coded in C++ and be compiled by a C++ > compiler. Am I right? Not necessarily. If we felt it desirable, the interface exposed for plug-ins could be C, not C++. However, I would expect it would be better to expose a C++ API. We'll have to see what consensus emerges on that point. (I do not feel that plug-ins should have full access to GCC's internals; I want to see a structured API that permits plug-ins access to a documented, stable interface.) > I would even imagine that later, one could configure GCC to have only a > C++ front-end, but no more a C one. I suppose, though thinking about that doesn't seem a great use of time at this point. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On Mon, 2010-05-31 at 12:33 -0700, Mark Mitchell wrote:
> Gabriel Dos Reis wrote:
>
> > OK, I will reformulate my question to you and Diego is: is this what we
> > want,
> > e.g. C++ as THE common implementation language, or just ONE common
> > implementation language (the other being C)?
>
> I believe that we want (a subset of) C++ to be the language used to
> implement all of GCC, including front-ends, back-ends, and common code.
>Where we currently use C, we wish to instead use C++.
You forgot to mention plugins. In my understanding, any future GCC
plugin would necessarily be coded in C++ and be compiled by a C++
compiler. Am I right?
The consequence would be that future GCC could be built on a system with
any C compiler, but only a C++ one.
I would even imagine that later, one could configure GCC to have only a
C++ front-end, but no more a C one. That probably would be unusual,
since many important applications which want to be compiled by GCC (I am
thinking of the Linux kernel) will continue to exist in C. But I would
believe that a future GCC with only a C++ frontend and without a C
frontend would be possible, and be able to bootstrap (i.e. make stage3),
which is not true today. IIRC, today's GCC (i.e. 4.5) cannot even be
configured to have a C++ front-end without having a C front-end. Do we
want to change that?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [RFC] Switching implementation language to C++
On 05/31/2010 06:22 PM, Diego Novillo wrote: Now that the SC and the FSF have agreed to this, we should decide whether we switch and how. So, I would like comments on the following questions: H, when I voted "yes" on the question "Requiring C++ Compiler for GCC Builds" (that was the subject of the mail to the Steering Committee mailing list to discuss this), I had the following in mind: 1- Should we switch to C++? Yes, otherwise I wouldn't have taken the time to ponder this. In fact, if not for the hordes of people that are only too eager to use every nook and cranny of the C++ language, I would have been much more supportive, as the situation we're finding ourselves in today is as if we were to write a Fortran 2003 compiler using only features from Fortran 77 plus (DE)ALLOCATE. This simply isn't leading us into a maintainable future. 2- What is the cost in terms of build time? Vladimir Makarov already addressed this. 3- What coding guidelines should we use? We might need some time to find the right coding standards for *our* use. What I wrote in my e-mail to the SC mailing list to support my stance was the following: "The useful part is to be able to use stl data structures and functions to do the hard work in the compiler instead of using specially-written tree-, list-, bitmap-, queue- and stack-creators, destroyers and walkers." because I think that would be *immediately* useful, as in ... 4- Should we make the switch during the 4.6 stage 1? ... version 4.6. Of course I agree with Richard Guenther that - *if done well and completely* - turning the tree data type into a class is desirable. However, that might simply be too much for the approximately 6 months remaining of 4.6's stage 1. Cheers, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 2:35 PM, Diego Novillo wrote: > On Mon, May 31, 2010 at 15:33, Mark Mitchell wrote: > >> I believe that we want (a subset of) C++ to be the language used to >> implement all of GCC, including front-ends, back-ends, and common code. >> Where we currently use C, we wish to instead use C++. > > That's what I want as well. OK, thanks to both of you. -- Gaby
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 15:33, Mark Mitchell wrote: > I believe that we want (a subset of) C++ to be the language used to > implement all of GCC, including front-ends, back-ends, and common code. > Where we currently use C, we wish to instead use C++. That's what I want as well. Diego.
Re: [RFC] Switching implementation language to C++
Gabriel Dos Reis wrote: > OK, I will reformulate my question to you and Diego is: is this what we want, > e.g. C++ as THE common implementation language, or just ONE common > implementation language (the other being C)? I believe that we want (a subset of) C++ to be the language used to implement all of GCC, including front-ends, back-ends, and common code. Where we currently use C, we wish to instead use C++. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 1:50 PM, Mark Mitchell wrote: > Gabriel Dos Reis wrote: > >> Yes, this is the sort of issues I have in mind. For example, I do not see >> how >> we can use C++ in tree.h without requiring other front-ends to use C++, at >> least >> for the parts that use tree.h. By components, I meant "for example, is it >> the >> case that the C++ front-end would use C++, but with sufficient care >> that it can be >> linked with the common C codes if the C front-end is not using C++?". > > Yes, I think it's possible for a front-end or a back-end to use C++ > without the rest of the compiler doing so. I doubt that's where we get > maximum bang from allowing use of C++, but it could certainly be done. OK, I will reformulate my question to you and Diego is: is this what we want, e.g. C++ as THE common implementation language, or just ONE common implementation language (the other being C)? I asking for the purpose of formulating tentative guidelines. -- Gaby
Re: [RFC] Switching implementation language to C++
Am 31.05.2010 20:50, schrieb Mark Mitchell: > Gabriel Dos Reis wrote: > >> Yes, this is the sort of issues I have in mind. For example, I do not see >> how >> we can use C++ in tree.h without requiring other front-ends to use C++, at >> least >> for the parts that use tree.h. By components, I meant "for example, is it >> the >> case that the C++ front-end would use C++, but with sufficient care >> that it can be >> linked with the common C codes if the C front-end is not using C++?". > > Yes, I think it's possible for a front-end or a back-end to use C++ > without the rest of the compiler doing so. I doubt that's where we get > maximum bang from allowing use of C++, but it could certainly be done. I think the C -> C++ switch is in terms of compiling GCC an all or nothing: You need have all of a sudden a C++ compiler for bootstrapping; otherwise, the middle end and all front ends should be C++ save thanks to to work of Ian et al. and -Wc++-compat. Thus, you get all the avantages and disadvantage of C++ and a C++ compiler everywhere. And as long as the code remains clear to a little-experience C++ compiler (at least, e.g., the middle-end code to which a front end programmer is exposed), I also do not see a problem for C++. Whether and to what extend the different parts of the compilers will switch, remains to be seen. I could imagine that some C++ will slowly creep in everywhere. Tobias, who is rather agnostic about the change, but who does not want to see overloaded operators of the type "+" or "*" (neither in C++ nor in Fortran).
Re: [RFC] Switching implementation language to C++
Gabriel Dos Reis wrote: > Yes, this is the sort of issues I have in mind. For example, I do not see how > we can use C++ in tree.h without requiring other front-ends to use C++, at > least > for the parts that use tree.h. By components, I meant "for example, is it the > case that the C++ front-end would use C++, but with sufficient care > that it can be > linked with the common C codes if the C front-end is not using C++?". Yes, I think it's possible for a front-end or a back-end to use C++ without the rest of the compiler doing so. I doubt that's where we get maximum bang from allowing use of C++, but it could certainly be done. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 1:25 PM, Mark Mitchell wrote: > Diego Novillo wrote: > >>> By switch, do you using a C++ compiler to compile everything, or that >>> some >>> components may be written only in C++ with sufficient care that they >>> can be >>> linked with other part written in C? >> >> Ideally, the former. If we cannot get consensus on that, then I guess >> we'd have to settle for the latter. > > I don't think a partial conversion strategy will be very successful. As > soon as we use C++ in tree.h, we're going to have to use it everywhere. > And, I suspect that using single inheritance in tree.h is the sort of > change that will cut down on a fair bit of casting, possibly helping us > to invalid conversions. > > That doesn't necessarily mean that we have to use lots of C++ features > everywhere. We can use the C (almost) subset of C++ if we want to in > some places. As an example, if the Fortran folks want to use C in the > Fortran front-end, then -- except to the extent required by the common > interfaces, those files could read as if they were C code. But, I think > they'd still need to be compiled with a C++ compiler because they'll > probably pull in headers that use C++ constructs. > Yes, this is the sort of issues I have in mind. For example, I do not see how we can use C++ in tree.h without requiring other front-ends to use C++, at least for the parts that use tree.h. By components, I meant "for example, is it the case that the C++ front-end would use C++, but with sufficient care that it can be linked with the common C codes if the C front-end is not using C++?". -- Gaby
Re: [RFC] Switching implementation language to C++
Diego Novillo wrote: >> By switch, do you using a C++ compiler to compile everything, or that >> some >> components may be written only in C++ with sufficient care that they >> can be >> linked with other part written in C? > > Ideally, the former. If we cannot get consensus on that, then I guess > we'd have to settle for the latter. I don't think a partial conversion strategy will be very successful. As soon as we use C++ in tree.h, we're going to have to use it everywhere. And, I suspect that using single inheritance in tree.h is the sort of change that will cut down on a fair bit of casting, possibly helping us to invalid conversions. That doesn't necessarily mean that we have to use lots of C++ features everywhere. We can use the C (almost) subset of C++ if we want to in some places. As an example, if the Fortran folks want to use C in the Fortran front-end, then -- except to the extent required by the common interfaces, those files could read as if they were C code. But, I think they'd still need to be compiled with a C++ compiler because they'll probably pull in headers that use C++ constructs. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 13:21, Michael Witten wrote: > On Mon, May 31, 2010 at 11:22, Diego Novillo wrote: >> Now that the SC and the FSF have agreed to this. > > When did this come up and why? Where can I read more about this? Was > there a thread I missed? Nevermind! It's a fairly recent thread :-)
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 11:22, Diego Novillo wrote: > Now that the SC and the FSF have agreed to this. When did this come up and why? Where can I read more about this? Was there a thread I missed?
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 11:54 AM, Diego Novillo wrote: > On 10-05-31 12:50 , Gabriel Dos Reis wrote: > >> By switch, do you using a C++ compiler to compile everything, or that some >> components may be written only in C++ with sufficient care that they can >> be >> linked with other part written in C? > > Ideally, the former. If we cannot get consensus on that, then I guess we'd > have to settle for the latter. OK, thanks for the clarification.
Re: [RFC] Switching implementation language to C++
On 10-05-31 12:50 , Gabriel Dos Reis wrote: By switch, do you using a C++ compiler to compile everything, or that some components may be written only in C++ with sufficient care that they can be linked with other part written in C? Ideally, the former. If we cannot get consensus on that, then I guess we'd have to settle for the latter. Diego.
Re: [RFC] Switching implementation language to C++
On Mon, May 31, 2010 at 11:22 AM, Diego Novillo wrote: > > Now that the SC and the FSF have agreed to this, we should decide whether we > switch and how. So, I would like comments on the following questions: > > 1- Should we switch to C++? By switch, do you using a C++ compiler to compile everything, or that some components may be written only in C++ with sufficient care that they can be linked with other part written in C? > 2- What is the cost in terms of build time? we would have to measure when we can a sizable component in C++ > 3- What coding guidelines should we use? this is under discussion :-) > 4- Should we make the switch during the 4.6 stage 1? 4.7? > > Questions 2-4 are predicated on the outcome of #1. > > We need volunteers to work on #3. I can help with #3 -- but not if we have to rehearse old debates :-/ > Personally, I would just use some other > existing coding guideline that we find reasonable. I agree. >I do not volunteer to do > this. My knowledge of C++ is sufficiently limited that I don't trust myself > to work on this. > > > Diego. >
[RFC] Switching implementation language to C++
Now that the SC and the FSF have agreed to this, we should decide whether we switch and how. So, I would like comments on the following questions: 1- Should we switch to C++? 2- What is the cost in terms of build time? 3- What coding guidelines should we use? 4- Should we make the switch during the 4.6 stage 1? Questions 2-4 are predicated on the outcome of #1. We need volunteers to work on #3. Personally, I would just use some other existing coding guideline that we find reasonable. I do not volunteer to do this. My knowledge of C++ is sufficiently limited that I don't trust myself to work on this. Diego.
