Re: Using C++ in GCC is OK
On 05/31/2010 12:30 PM, 徐持恒 wrote: I think compiler can and should be host independent, like LLVM. It is. Changes to code generation depending on the host are considered to be serious bugs, and have been long before LLVM existed. Paolo
Re: Using C++ in GCC is OK
On Mon, 31 May 2010 18:24:00 -0400, Joern Rennecke wrote: > Quoting Vladimir Makarov : >> Reviewers are frequently busy. I bet not a lot of reviewers apply >> patches and play with it. >> >> So it would be nice that people who submits such patches report changes >> in compile time/footprint/build time (at least I am going to ask this >> for parts which I review even if such changes in these parts will be >> not critical for whole compiler as tree or rtl infrastructure changes). >> Otherwise, we are in danger to get slowly degrading compiler. > > I'm not sure that this will be effective against bloat creep. When > considering one small patch that slows down the compiler (and/or slows down > build time) by 0.1%, the difference will be in the noise and impossible to > measure with a manageable sample size. > But if you combine 1100 of such small patches, the compiler will be three > times slower. > > So, unless we can get some coding style/review mechanism in place that > prevents > such bloat creep by examining the source code change and the area where it > is > applied, I think we would need a way to magnify the performance impact > of abstraction penalties. E.g. if the penalty is a vtable lookup, making > it take a hundred times more specifically in the changed places would > magnify the 0.1% overall change to a measurable delta of 10%. Your argument is applicable to any changes in GCC, not just to C to C++ conversions. Do patches that slow down the current C code base by 0.1% get rejected? They do not. -- VH
Re: Using C++ in GCC is OK
On 01/06/10 10:03, Paolo Bonzini wrote: On 05/31/2010 12:30 PM, 徐持恒 wrote: I think compiler can and should be host independent, like LLVM. It is. Changes to code generation depending on the host are considered to be serious bugs, and have been long before LLVM existed. Perhaps 徐持恒 meant target independent, in the sense that with LLVM the choice of target is made at run-time, and not when building LLVM [*]. Just a guess though. Ciao, Duncan. [*] It is possible to choose which targets to build when configuring LLVM. If only one is chosen then of course that's the only one that can be chosen at run-time.
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 10:22 AM, Duncan Sands wrote: > [*] It is possible to choose which targets to build when configuring LLVM. > If only one is chosen then of course that's the only one that can be chosen > at run-time. This should eventually be made possible in GCC too. It's what all the target macro to target hook conversion is about (although that in itself is not enough). Ciao! Steven
Re: Using C++ in GCC is OK
On 05/31/2010 06:26 PM, Basile Starynkevitch wrote: On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote: There's no reason to get into these kinds of questions at this point. The goal is not to reimplement GCC from the ground up using modern OO/C++ techniques. The goal is simply to permit ourselves to use C++ features where appropriate in the codebase. Except that perhaps these questions are important for any gengtype enhancement. In particular, one could consider that marking a GTY-ed data would be done by a virtual method (generated by gengtype), and then having every GTY-ed data inheriting from an abstract class providing this method will make both gengtype& ggc*.c simpler. The same can be said about PCH serialization, or debug dumping. I'm not sure. Virtual methods have the overhead of a pointer in the object, while gengtype does 100% static typing so it doesn't need a virtual method. Also, in general compiler IRs are used in so many places that a "pattern matching" style (similar to ML) actually works better than a "class hierarchy" style. In other words, I doubt that C++ would remove many of the switch statements we have in the code. With respect to this, I'm curious about Ian's experience with gccgo. Adjusting RTL and trees involve a huge rewrite effort, as pointed out elsewhere in the thread, and in the end our own DSL would probably suit the task just as well (or better). In particular, our trees have a kind of multiple inheritance. Personally, the first place where I'd start using C++ is the pass manager. Even then, I'm wary about the compile-time cost of passing "this" around all the time. But then I have no time for anything of this, so I can just as well shut up. Paolo
Re: Using C++ in GCC is OK
Hello On 01.06.10, you wrote: > making >> it take a hundred times more specifically in the changed places would >> magnify the 0.1% overall change to a measurable delta of 10%. > Your argument is applicable to any changes in GCC, not just to C to C++ > conversions. Do patches that slow down the current C code base by 0.1% get > rejected? They do not. compile a program in g++ mode really slowdown lots.A build of GCC need on my system 25 minutes, when gcc compile in g++ mode i think it need to compile more than 1 hour. you can see that when you look at C++ programs with same exe size.compile time is around 3* higher in compare to C program, even if c++ is called not make so small code. when i look on Visual C++ in C++ programs i see not so much slowdown. maybe G++ can speedup in any way ? > > -- > VH > Regards
Re: Loops no longer vectorized
Ira, Thanks for the answer. > The loop that got vectorized in the older revision is another loop > associated with the same source code line: Upon further investigation this loops is likely related to a temporary that have been removed in recent versions. Using the older revision with -Warray-temporaries gives: ... induct.f90:5057.30: xmin = minval(nodes(1,inductor_number(1:number_of_nodes))) 1 Warning: Creating array temporary at (1) ... not present in more recent revisions. Dominique
Re: [Bug rtl-optimization/44013] VTA produces wrong code
Hi Jakub, I have not had any response from Alexandre on this yet and i haven't had much luck in mailing list either (http://gcc.gnu.org/ml/gcc/2010-04/msg00917.html). Is there anyone else who is familiar with VTA who could help? Thanks Hari jakub at gcc dot gnu dot org wrote:
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: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)
On Thu, Feb 18, 2010 at 1:26 AM, Paolo Bonzini wrote: >>> Maybe we can use this in AC_CHECK_DECLS instead of having a new >>> separate macro. If there is a parenthesis in the name call the new >>> version, if there is none, call the old one. >> >> You shouldn't need to keep the old version around, it's supposed to be >> a drop-in replacement. The reason I used a new name was that I'm not >> sure if GCC project can wait till we have a suitable macro in autoconf. > > Yes, I saw that now in the libcpp part of your patch. That's even better! > >> Even if you put it now into the autoconf codebase, GCC would presumably >> have to wait for some time after the next release to use it. > > We have a mechanism for importing code from newer Autoconf versions > (in config/override.m4). Any progress here? If we want to switch on --enable-build-with-cxx by default then this has to be addressed. Richard. > Paolo >
Re: Using C++ in GCC is OK
Paolo Bonzini writes: > Also, in general compiler IRs are used in so many places that a > "pattern matching" style (similar to ML) actually works better than a > "class hierarchy" style. In other words, I doubt that C++ would > remove many of the switch statements we have in the code. With > respect to this, I'm curious about Ian's experience with gccgo. In the gccgo IR I don't represent everything with a single type. Instead, I use a separate base class for types, expressions and statements (in Go there is more of a distinction between expressions and statements than there is in C/C++). I represent specific types, etc., as child classes. The base class uses a protected virtual function interface which the child classes implement. However, as you observe, some code does need to use pattern matching, so that approach is awkward to use by itself. I also declare an enum in the base class, and so given a pointer to the base class you can examine that enum to know which kind of object you have. Some operations are naturally described as virtual functions, such as converting to GENERIC or the general IR walker. Others are naturally described by examining the enums, such as checking whether two types are compatible. The main advantage of using virtual functions in the IR is that it significantly reduces the number of switch statements that have to be updated to add a new kind of IR. Instead most of the operations are kept in one place, in the child class implementation. To be clear, I don't think it would be appropriate at this time to use virtual functions for trees, GIMPLE, or RTL. Ian
Re: Using C++ in GCC is OK
I would highly suggest looking at google guidelines. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml They are aimed at taking some of the landlines out of c++ and give pros and cons for each argument. There are many places in the gcc source where we are already doing C++ things. I would think those would be the best places to start. Adding classes (especially with inheritance) should not be a development decision but instead a design decision. To really move towards C++ we really need to develop a model of what we would like the code to look like.
Reverted bogus commit in rev 160105
I fat-fingered what I thought was a git local command, and committed revision 160105 with bogus changes. If you have rev 160105 checked out, please update your tree. Apologies for the mix up. I'll go hide now. Diego.
Re: Using C++ in GCC is OK
Ian Lance Taylor wrote: > I have written a proposed set of C++ coding conventions on the wiki at > http://gcc.gnu.org/wiki/CppConventions > > This is only a preliminary proposal. It requires fleshing out and > discussion. Thank you for volunteering to do this. How would you like to receive comments? Directly on the Wiki page, or by email? Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell wrote: > Ian Lance Taylor wrote: > >> I have written a proposed set of C++ coding conventions on the wiki at >> http://gcc.gnu.org/wiki/CppConventions >> >> This is only a preliminary proposal. It requires fleshing out and >> discussion. > > Thank you for volunteering to do this. How would you like to receive > comments? Directly on the Wiki page, or by email? Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. though. I'd also like to avoid destructors where possible as we want as many core data types to be POD. Btw - can we intially just link with libsup++ omitting libstdc++ so that we do not get the expected flood of convert-to-STL patches? Or is the idea of an STL free gcc bad? Thanks, Richard.
Re: Using C++ in GCC is OK
Mark Mitchell writes: > Ian Lance Taylor wrote: > >> I have written a proposed set of C++ coding conventions on the wiki at >> http://gcc.gnu.org/wiki/CppConventions >> >> This is only a preliminary proposal. It requires fleshing out and >> discussion. > > Thank you for volunteering to do this. How would you like to receive > comments? Directly on the Wiki page, or by email? Hmmm, good question. I guess either is fine, but it's probably simpler if people add comments directly on the wiki page. For simplicity, I suggest that unless you are correcting a typo or other obvious error, put additions or comments in parentheses or in a separate bullet item with your name attached. As the wiki page says, when this converges it will be moved to a .html page under CVS control. Ian
Include files search order of cross build gcc
Hi, When I cross build gcc on linux-amd64 box, I got a include files search order error: ... /root/obj/gcc-4.2/./gcc/xgcc -B/root/obj/gcc-4.2/./gcc/ -L/root/obj/gcc-4.2/i686-pc-mingw32/winsup/mingw -L/root/obj/gcc-4.2/i686-pc-mingw32/winsup/w32api/lib -isystem /root/src/gcc-4.2.4/winsup/mingw/include -isystem /root/src/gcc-4.2.4/winsup/w32api/include -B/root/mingw32/i686-pc-mingw32/bin/ -B/root/mingw32/i686-pc-mingw32/lib/ -isystem /root/mingw32/i686-pc-mingw32/include -isystem /root/mingw32/i686-pc-mingw32/sys-include -O2 -I/root/src/gcc-4.2.4/gcc/../winsup/w32api/include -O2 -O2 -pipe -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/root/src/gcc-4.2.4/gcc -I/root/src/gcc-4.2.4/gcc/. -I/root/src/gcc-4.2.4/gcc/../include -I/root/src/gcc-4.2.4/gcc/../libcpp/include -I/usr/include -I/usr/include -I/root/src/gcc-4.2.4/gcc/../libdecnumber -I../libdecnumber -c /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c -o libgcc/./gthr-win32.o In file included from /usr/include/sys/select.h:46, from /usr/include/sys/types.h:220, from /usr/include/stdlib.h:320, from /root/mingw32/i686-pc-mingw32/include/objbase.h:12, from /root/mingw32/i686-pc-mingw32/include/ole2.h:9, from /root/mingw32/i686-pc-mingw32/include/windows.h:114, from /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c:34: /usr/include/bits/time.h:70: error: redefinition of ‘struct timeval’ In file included from /usr/include/sys/types.h:220, from /usr/include/stdlib.h:320, from /root/mingw32/i686-pc-mingw32/include/objbase.h:12, from /root/mingw32/i686-pc-mingw32/include/ole2.h:9, from /root/mingw32/i686-pc-mingw32/include/windows.h:114, from /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c:34: Why gcc use stdlib.h in the path '/usr/include', not the path '/root/mingw32/i686-pc-mingw32/include' ? Regards, Dongsheng
Re: Using C++ in GCC is OK
Richard Guenther wrote: > Btw - can we intially just link with libsup++ omitting libstdc++ so > that we do not get the expected flood of convert-to-STL patches? > Or is the idea of an STL free gcc bad? I view STL as one of the bits of low-hanging C++ fruit. I think we're all vaguely confused by the VEC APIs, for example; using std::vector seems much better. And, using those kinds of things doesn't require a lot of knowledge of C++ arcana, even if the implementations may use some of that arcana. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
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: Using C++ in GCC is OK
Hi, I hope you don't mind my comment as I an not a project member, just a long term multi-platform GCC user. With all due respect, I fail to understand the decision to switch to C++ without being able to elucidate the specific features of C++ that will benefit the GCC team and the GCC compiler collection. It seems to me that outlining the specific advantages to both the compiler and development team of using C++ over C would be step one in defining what is and is not to be allowed. (I'm sure there is such a document, but I haven't been able to find it.) To begin, what are the specific reasons or advantages for switching to C++ for the GCC compiler? Will C++ produce faster or more efficient code and if so how and using what specific constructs? Will using C++ produce less buggy code and, again, if so how and using what specific constructs. And so forth. Each specific reason for using C++ over C should have clear and definable benefits for both current and future developers and product; each of these benefits should form the basis for the coding standards for the GCC project. One final note: it is my experience that having developers not using the tool/product they are developing reduces product quality dramatically. For the one cent my two cents is worth, the C front end should be written in C, the C++ front end should be written in C++ and so forth. Thanks again to the whole compiler team for the great work and great products. Rich Wallick 19255 NW North Star Dr. Banks, OR 97016 503 324 9189
Re: Using C++ in GCC is OK
Richard Guenther wrote: On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell wrote: Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Thank you for volunteering to do this. How would you like to receive comments? Directly on the Wiki page, or by email? Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. which do you want to disallow, the "may" or the "only", not clear \
Re: Using C++ in GCC is OK
Mark Mitchell writes: > Richard Guenther wrote: > >> Btw - can we intially just link with libsup++ omitting libstdc++ so >> that we do not get the expected flood of convert-to-STL patches? >> Or is the idea of an STL free gcc bad? > > I view STL as one of the bits of low-hanging C++ fruit. I think we're > all vaguely confused by the VEC APIs, for example; using std::vector > seems much better. And, using those kinds of things doesn't require a > lot of knowledge of C++ arcana, even if the implementations may use some > of that arcana. Agreed. In particular, we can take advantage of the cool new gdb work to easily print vectors and other STL types in the debugger. Dealing with VECs in the debugger is a pain. Ian
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: Using C++ in GCC is OK
Richard Guenther writes: > Overall the wiki document looks good. I'd like to disallow > > * Operators may only be overloaded for types which implement numeric > values, where the overloaded operators implement the usual numeric > semantics. > > though. My thinking here is that it would be reasonable to implement real_arithmetic and mpfr/mpc using overloaded operators. I could certainly be wrong. > I'd also like to avoid destructors where possible as we want > as many core data types to be POD. I adjusted the wiki accordingly. Ian
Re: Include files search order of cross build gcc
Dongsheng Song writes: > When I cross build gcc on linux-amd64 box, I got a include files > search order error: This question is not appropriate for the mailing list g...@gcc.gnu.org. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. > /root/obj/gcc-4.2/./gcc/xgcc -B/root/obj/gcc-4.2/./gcc/ > -L/root/obj/gcc-4.2/i686-pc-mingw32/winsup/mingw > -L/root/obj/gcc-4.2/i686-pc-mingw32/winsup/w32api/lib -isystem > /root/src/gcc-4.2.4/winsup/mingw/include -isystem > /root/src/gcc-4.2.4/winsup/w32api/include > -B/root/mingw32/i686-pc-mingw32/bin/ > -B/root/mingw32/i686-pc-mingw32/lib/ -isystem > /root/mingw32/i686-pc-mingw32/include -isystem > /root/mingw32/i686-pc-mingw32/sys-include -O2 > -I/root/src/gcc-4.2.4/gcc/../winsup/w32api/include -O2 -O2 -pipe > -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition > -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 > -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. > -I/root/src/gcc-4.2.4/gcc -I/root/src/gcc-4.2.4/gcc/. > -I/root/src/gcc-4.2.4/gcc/../include > -I/root/src/gcc-4.2.4/gcc/../libcpp/include -I/usr/include > -I/usr/include -I/root/src/gcc-4.2.4/gcc/../libdecnumber > -I../libdecnumber -c /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c > -o libgcc/./gthr-win32.o > In file included from /usr/include/sys/select.h:46, > from /usr/include/sys/types.h:220, > from /usr/include/stdlib.h:320, > from /root/mingw32/i686-pc-mingw32/include/objbase.h:12, > from /root/mingw32/i686-pc-mingw32/include/ole2.h:9, > from /root/mingw32/i686-pc-mingw32/include/windows.h:114, > from /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c:34: > /usr/include/bits/time.h:70: error: redefinition of ‘struct timeval’ > In file included from /usr/include/sys/types.h:220, > from /usr/include/stdlib.h:320, > from /root/mingw32/i686-pc-mingw32/include/objbase.h:12, > from /root/mingw32/i686-pc-mingw32/include/ole2.h:9, > from /root/mingw32/i686-pc-mingw32/include/windows.h:114, > from /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c:34: > > Why gcc use stdlib.h in the path '/usr/include', not the path > '/root/mingw32/i686-pc-mingw32/include' ? Because there is an explicit -I/usr/include in the compilation line. I don't know where that is coming from. It seems likely that you should be using --with-sysroot on your configure line; see the installation instructions. Ian
Re: Using C++ in GCC is OK
Rich Wallick writes: > I hope you don't mind my comment as I an not a project member, just a > long term multi-platform GCC user. With all due respect, I fail to > understand the decision to switch to C++ without being able to elucidate > the specific features of C++ that will benefit the GCC team and the GCC > compiler collection. It seems to me that outlining the specific > advantages to both the compiler and development team of using C++ over > C would be step one in defining what is and is not to be allowed. (I'm > sure there is such a document, but I haven't been able to find it.) Here are the slides from my presentation on the topic at the 2008 GCC Summit: http://airs.com/ian/cxx-slides.pdf . > To begin, what are the specific reasons or advantages for switching > to C++ for the GCC compiler? See above slides for my summary. > Will C++ produce faster or more efficient > code and if so how and using what specific constructs? Using C++ in the compiler will not produce faster or more efficient generated code. In some cases it should make the compiler itself run more efficiently, as when using STL sort rather than qsort. > Will using C++ > produce less buggy code and, again, if so how and using what specific > constructs. My hope is that using C++ in the compiler should help make the compiler itself less buggy, in particular in areas related to memory use. > One final note: it is my experience that having developers not using > the tool/product they are developing reduces product quality > dramatically. For the one cent my two cents is worth, the C front end > should be written in C, the C++ front end should be written in C++ and > so forth. I do hope that writing gcc in C++ will increase the performance of the C++ frontend. I'm skeptical that it will have any negative effect on the C frontend. Ian
Re: Using C++ in GCC is OK
On Tue, 2010-06-01 at 10:33 -0700, Ian Lance Taylor wrote:
> Here are the slides from my presentation on the topic at the 2008 GCC
> Summit: http://airs.com/ian/cxx-slides.pdf .
Ian, what is that status of your GCC in C++ branch? What should be
re-usable from it? Do you think it makes sense to reuse it, or was it a
proof of concept only work?
[I admit I never took time to look in detail into your branch]
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 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++
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: Using C++ in GCC is OK
Basile Starynkevitch writes: > On Tue, 2010-06-01 at 10:33 -0700, Ian Lance Taylor wrote: >> Here are the slides from my presentation on the topic at the 2008 GCC >> Summit: http://airs.com/ian/cxx-slides.pdf . > > > Ian, what is that status of your GCC in C++ branch? What should be > re-usable from it? Do you think it makes sense to reuse it, or was it a > proof of concept only work? > > [I admit I never took time to look in detail into your branch] I merged the branch into mainline last year. Ian
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++
* 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++
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++
* 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.
Vector indexing patch
This is a reworked patch of Andrew Pinski "Subscripting on vector
types" in terms of GSoC 2010 [Artjoms Sinkarovs].
This patch allows to index individual elements of vector type in C.
For example: vec[i], where vec is a vector with a base type T and i is
an integer type.
If i is a constant then we construct a BIT_FIELD_REF node considering
boundchecking, otherwise we expand it to (((T *)&(vec))[i]).
If the vector type variable has a register storage class then it can
be accessed only via constant index.
Changelog:
gcc/c-common.h: helper function c_build_vector_indexed_by_cst added
gcc/c-common.c: helper function c_build_vector_indexed_by_cst added
gcc/c-typeck.c: build_array_ref modified to handle vector indexing,
lvalue_p modified for considering vector element as lvalue.
gcc/testsuite/gcc.c-torture/execute/vector-subscript-1.c: test taken
from A.Pinski patch
gcc/testsuite/gcc.c-torture/execute/vector-subscript-2.c: test taken
from A.Pinski patch
gcc/testsuite/gcc.dg/vector-subscript-3.c: new test
gcc/testsuite/gcc.dg/array-8.c: Update error message about subscripting
gcc/testsuite/gcc.dg/vector-subscript-1.c: test taken from A.Pinski patch
gcc/testsuite/gcc.dg/vector-subscript-2.c: test taken from A.Pinski patch
Teseted on x86_64-unknown-linux-gnu.
The documentation was not changed. May be there could be some more
ideas to implement.
The patch can be found in attachment.
___ C++ related question ___
Question about C++ frontend people. I would like to implement the same
functionality in C++ frontend and typechecker as well. However the
problem is that at the moment I have the same code in typechecker and
in the decl2.c file (part of frontend). The code looks like this:
Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 159699)
+++ gcc/cp/typeck.c (working copy)
@@ -2912,7 +2912,30 @@
default:
break;
}
+
+ /* For vector[index], convert the vector to a pointer of the underlying
+ type. */
+ if (TREE_CODE (TREE_TYPE (array)) == VECTOR_TYPE)
+{
+ tree type = TREE_TYPE (array);
+ tree type1;
+
+ if (TREE_CODE (idx) == INTEGER_CST)
+c_build_vector_indexed_by_cst (loc, array, idx);
+ else
+{
+ /* Mark the vector as addressable but ignore the
+ register storage class. */
+ cxx_mark_addressable (array);
+ type = build_qualified_type (TREE_TYPE (type), TYPE_QUALS (type));
+ type = build_pointer_type (type);
+ type1 = build_pointer_type (TREE_TYPE (array));
+ array = build1 (ADDR_EXPR, type1, array);
+ array = convert (type, array);
+}
+}
+
if (TREE_CODE (TREE_TYPE (array)) == ARRAY_TYPE)
{
tree rval, type;
Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c (revision 159699)
+++ gcc/cp/decl2.c (working copy)
@@ -365,7 +365,30 @@
else
{
tree p1, p2, i1, i2;
+ /* For vector[index], convert the vector to a pointer of the underlying
+type. */
+ if (TREE_CODE (type) == VECTOR_TYPE)
+ {
+ tree type = TREE_TYPE (array_expr);
+ tree type1;
+ /* If constant index is in bound of vector type */
+ if (TREE_CODE (index_exp) == INTEGER_CST)
+ c_build_vector_indexed_by_cst (input_location, array_expr,
+index_exp);
+ else
+{
+ /* Mark the vector as addressable but ignore the
+ register storage class. */
+ cxx_mark_addressable (array_expr);
+ type = build_qualified_type (TREE_TYPE (type),
TYPE_QUALS (type));
+ type = build_pointer_type (type);
+ type1 = build_pointer_type (TREE_TYPE (array_expr));
+ array_expr = build1 (ADDR_EXPR, type1, array_expr);
+ array_expr = convert (type, array_expr);
+}
+}
+
/* Otherwise, create an ARRAY_REF for a pointer or array type.
It is a little-known fact that, if `a' is an array and `i' is
My question is whether I can be sure that the tree that I'll have in
typeck.c will be passed through the decl2.c? In that case I will be
able to avoid code doubling in typeck.c just skipping this check.
Because I can be sure that the code will be checked in decl2.c.
Can anyone give me a quick description of the C++ front end. Or point
me to the right document.
--
Thank you,
Artem Shinkarov
Index: gcc/testsuite/gcc.c-torture/execute/vector-subscript-2.c
===
--- gcc/testsuite/gcc.c-torture/execute/vector-subscript-2.c (revision 0)
+++ gcc/testsuite/gcc.c-torture/execute/vector-subscript-2.c (revision 0)
@@ -0,0 +1,66 @@
+#define vector __attribute__((vector_size(sizeof(int)*4) ))
+
+/* Check to make
Re: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)
[ moving from autoconf@ to -patches ]
* Richard Guenther wrote on Tue, Jun 01, 2010 at 01:52:07PM CEST:
>
> Any progress here? If we want to switch on --enable-build-with-cxx
> by default then this has to be addressed.
Proposed patches for Autoconf. Tested with CC=g++ in TESTSUITEFLAGS and
without.
One remaining nit is that the configure cache variables carry the whole
signature, are quite long, and sensitive to white space in the
declaration. Oh well. Any other issues with it?
Thanks, and sorry for the long delay,
Ralf
>From dbfbf0d2e550d7d304f5fb8edfa5a340aebc4d21 Mon Sep 17 00:00:00 2001
From: Joern Rennecke
Date: Tue, 1 Jun 2010 20:06:54 +0200
Subject: [PATCH 1/2] Generalize AC_CHECK_DECL for C++: allow optional arguments.
* general.m4 (_AC_CHECK_DECL_BODY): Process trailing function
argument types as arguments to use for C++.
(_AC_CHECK_DECLS): Filter out trailing function argument types
when henerating the HAVE_DECL_* macro.
Signed-off-by: Ralf Wildenhues
---
ChangeLog |8
lib/autoconf/general.m4 | 15 +++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 1452eb3..8041556 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-06-01 Joern Rennecke(tiny change)
+
+ Generalize AC_CHECK_DECL for C++: allow optional arguments.
+ * general.m4 (_AC_CHECK_DECL_BODY): Process trailing function
+ argument types as arguments to use for C++.
+ (_AC_CHECK_DECLS): Filter out trailing function argument types
+ when henerating the HAVE_DECL_* macro.
+
2010-05-25 Stefano Lattarini
Eric Blake
diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index b7ac62f..fecfb72 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -2792,10 +2792,16 @@ AC_DEFUN([AC_CHECK_FILES],
# Shell function body for AC_CHECK_DECL.
m4_define([_AC_CHECK_DECL_BODY],
[ AS_LINENO_PUSH([$[]1])
- AC_CACHE_CHECK([whether $[]2 is declared], [$[]3],
+ [as_decl_name=`echo $][2|sed 's/(.*//'`]
+ [as_decl_use=`echo $][2|sed -e 's/(/((/' -e 's/)/) 0&/' -e 's/,/) 0& (/g'`]
+ AC_CACHE_CHECK([whether $as_decl_name is declared], [$[]3],
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([$[]4],
-...@%:@ifndef $[]2
- (void) $[]2;
+...@%:@ifndef $[]as_decl_name
+...@%:@ifdef __cplusplus
+ (void) $[]as_decl_use;
+...@%:@else
+ (void) $[]as_decl_name;
+...@%:@endif
@%:@endif
])],
[AS_VAR_SET([$[]3], [yes])],
@@ -2831,7 +2837,8 @@ AS_VAR_POPDEF([ac_Symbol])dnl
# ACTION-IF-FOUND or ACTION-IF-NOT-FOUND.
m4_define([_AC_CHECK_DECLS],
[AC_CHECK_DECL([$1], [ac_have_decl=1], [ac_have_decl=0], [$4])]dnl
-[AC_DEFINE_UNQUOTED(AS_TR_CPP([HAVE_DECL_$1]), [$ac_have_decl],
+[AC_DEFINE_UNQUOTED(AS_TR_CPP(m4_bpatsubst(HAVE_DECL_[$1],[(.*])),
+ [$ac_have_decl],
[Define to 1 if you have the declaration of `$1',
and to 0 if you don't.])]dnl
[m4_ifvaln([$2$3], [AS_IF([test $ac_have_decl = 1], [$2], [$3])])])
--
1.7.0.rc1.161.g90487
>From ef0cd33aa5bc626a4a0063062aaae5fd80bf185f Mon Sep 17 00:00:00 2001
From: Ralf Wildenhues
Date: Tue, 1 Jun 2010 21:54:39 +0200
Subject: [PATCH 2/2] Documentation and tests for the AC_CHECK_DECL change.
* lib/autoconf/general.m4 (_AC_CHECK_DECL_BODY): Squash trailing
spaces in as_decl_name.
(_AC_CHECK_DECLS): Likewise for the define.
* tests/semantics.at (AC_CHECK_DECLS): Extend test.
* doc/autoconf.texi (Generic Declarations): Update.
* NEWS: Update.
Signed-off-by: Ralf Wildenhues
---
ChangeLog | 10 ++
NEWS|3 +++
doc/autoconf.texi | 14 +++---
lib/autoconf/general.m4 |4 ++--
tests/semantics.at | 35 +--
5 files changed, 59 insertions(+), 7 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 8041556..08bcde8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2010-06-01 Ralf Wildenhues
+
+ Documentation and tests for the AC_CHECK_DECL change.
+ * lib/autoconf/general.m4 (_AC_CHECK_DECL_BODY): Squash trailing
+ spaces in as_decl_name.
+ (_AC_CHECK_DECLS): Likewise for the define.
+ * tests/semantics.at (AC_CHECK_DECLS): Extend test.
+ * doc/autoconf.texi (Generic Declarations): Update.
+ * NEWS: Update.
+
2010-06-01 Joern Rennecke(tiny change)
Generalize AC_CHECK_DECL for C++: allow optional arguments.
diff --git a/NEWS b/NEWS
index afd8907..04cf8dd 100644
--- a/NEWS
+++ b/NEWS
@@ -16,6 +16,9 @@ GNU Autoconf NEWS - User visible changes.
** Autoconf should work on EBCDIC hosts.
+** AC_CHECK_DECL and AC_CHECK_DECLS accept optional function argument types
+ for overloaded C++ functions.
+
* Major changes in Autoconf 2.65 (2009-11-21) [stable]
Released by Eric Blake, based on git versions 2.64.*.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 3df0d3f..eab9ab2 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -6275,8 +6275,14 @@ Generic Declarations
This macro actually tests whether @var{symbol} is defined as a macro or
can
Re: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)
On 06/01/2010 02:06 PM, Ralf Wildenhues wrote: > Any other issues with it? > Subject: [PATCH 1/2] Generalize AC_CHECK_DECL for C++: allow optional > arguments. > > * general.m4 (_AC_CHECK_DECL_BODY): Process trailing function > argument types as arguments to use for C++. > (_AC_CHECK_DECLS): Filter out trailing function argument types > when henerating the HAVE_DECL_* macro. s/henerating/generating/ (ChangeLog and commit message) Other than that, please push. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Using C++ in GCC is OK
My suggestions: * When it is appropriate to use a child class with virtual functions, the virtual functions should all be declared as protected in the parent class. At first reading, I thought you meant "all virtual functions should be protected", but I think you meant "if a child ADDS a virtual function that the parent doesn't have, ...", but in that case I don't see why the parent needs a declaration at all. This should be clarified. * Namespaces In general, I don't like namespaces, unless you're defining a package. Class names create their own name spaces, globals should be global, etc. Saying "everything should be in a namespace" is IMHO an inappropriate restriction. Indicate where namespaces are appropriate, leave it at that. * All data members should be private. * All data members should have names which end with an underscore. This makes all structures illegal. I'd remove the first "All" and replace the second with "Private": * Data members should be private. * Private data members should have names which end with an underscore. * When a method refers to a non-static data member, it should always qualify the reference with this->. I'm very opposed to this. To me, it makes the code less readable because it lets the author write code that's hard to understand at a larger scope. I would forbid explicit references to "this" except to pass it unadorned as a parameter to some other function. If it's not clear where method call data comes from, write clearer code! If you're implementing a class, it should be clear you're implementing a class, and implied that data/methods come from the class unless specified otherwise (which you'd have to do anyway, like foo->reg_p()). If it's not clear, you've not properly encapsulated the class and you need to redesign it so it *is* properly contained and easy to understand. If you're not implementing a class, you'd never use "this" anyway. DJ never refers to himself in the third person, I don't see why his code should. * At least for now we will continue to use printf style I/O rather than style I/O THANK YOU! * use of existing templates, e.g., from the standard library, is fine I'd prefer avoiding pulling in STL stuff at first. I find STL to be quite a "culture shock" relative to C. When used I'd limit it to one STL object at a time - avoid containers of lists of vectors of strings, etc. Additions: * Local variables should be declared where they're first used, if their use is contiguous and localized. If they're ubiquitous (like a return value temporary) or reused later (like "i" for for-loop iterators), declare them at the beginning of the function. * Use C-style comments for multi-line comments, and C++-style comments for single-line comments.
Re: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)
On 06/01/2010 02:06 PM, Ralf Wildenhues wrote: > [ moving from autoconf@ to -patches ] > > * Richard Guenther wrote on Tue, Jun 01, 2010 at 01:52:07PM CEST: >> >> Any progress here? If we want to switch on --enable-build-with-cxx >> by default then this has to be addressed. > > Proposed patches for Autoconf. Tested with CC=g++ in TESTSUITEFLAGS and > without. > > One remaining nit is that the configure cache variables carry the whole > signature, are quite long, and sensitive to white space in the > declaration. Oh well. Any other issues with it? Yeah, we've had other cache variables that are sensitive to whitespace (think AC_CHECK_MEMBER), so maybe it would be worth a patch to normalize both of those before converting to a cache name. > > Thanks, and sorry for the long delay, And sorry for my delay in not spending enough time to get an autoconf 2.66 release out the door. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
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: Using C++ in GCC is OK
DJ Delorie writes: > My suggestions: > > * When it is appropriate to use a child class with virtual functions, >the virtual functions should all be declared as protected in the >parent class. > > At first reading, I thought you meant "all virtual functions should be > protected", but I think you meant "if a child ADDS a virtual function > that the parent doesn't have, ...", but in that case I don't see why the > parent needs a declaration at all. This should be clarified. I did mean that all virtual functions should be protected. I tried to clarify the wiki page. > * Namespaces > > In general, I don't like namespaces, unless you're defining a package. > Class names create their own name spaces, globals should be global, etc. > Saying "everything should be in a namespace" is IMHO an inappropriate > restriction. Indicate where namespaces are appropriate, leave it at > that. The proposal doesn't say that everything should be in a namespace; it says that namespaces are permitted. I continue to think that is appropriate. I agree that globals should be global. However, GCC is a big package which can be naturally divided into modules. For example, GIMPLE code should not normally call RTL functions. Putting the RTL functions in a namespace would make it clear when something is reaching across a module boundary. Of course there are other ways to do this as well, but my point is that "global is global" is not necessary a well-defined concept in a big program. Some names are global to parts of the program but not to others. > * All data members should be private. > * All data members should have names which end with an underscore. > > This makes all structures illegal. I'd remove the first "All" and > replace the second with "Private": This text only refers to classes. As the convention says in the following major bullet, structs are handled as they are today. > * When a method refers to a non-static data member, it should always >qualify the reference with this->. > > I'm very opposed to this. To me, it makes the code less readable > because it lets the author write code that's hard to understand at a > larger scope. I would forbid explicit references to "this" except to > pass it unadorned as a parameter to some other function. If it's not > clear where method call data comes from, write clearer code! > > If you're implementing a class, it should be clear you're implementing a > class, and implied that data/methods come from the class unless > specified otherwise (which you'd have to do anyway, like foo->reg_p()). > If it's not clear, you've not properly encapsulated the class and you > need to redesign it so it *is* properly contained and easy to > understand. > > If you're not implementing a class, you'd never use "this" anyway. > > DJ never refers to himself in the third person, I don't see why his code > should. Our current code always uses the equivalent of an explicit this pointer, except that it is called something else. Therefore I would argue that this is not new. I don't see why using an explicit this-> makes code harder to understand in a larger scope; the explicit this-> makes it very clear where data is coming from. The biggest need for this-> is when calling methods in the current class if the current class happens to be in a template. The C++ template namespace lookup rules are confusing. The explicit this-> makes them clear. While it's true that most code is not in a template, it's possible that a template will be added later. I'm not going to fight to the death on this one, and I would be interested in hearing other opinions. I've been using explicit this-> in my own C++ code for many years, and I find that it clarifies rather than confuses. > * use of existing templates, e.g., from the standard library, is fine > > I'd prefer avoiding pulling in STL stuff at first. I find STL to be > quite a "culture shock" relative to C. When used I'd limit it to one > STL object at a time - avoid containers of lists of vectors of strings, > etc. As noted earlier I think we do want to use some STL classes. > * Local variables should be declared where they're first used, if their > use is contiguous and localized. If they're ubiquitous (like a return > value temporary) or reused later (like "i" for for-loop iterators), > declare them at the beginning of the function. Thanks, I added text along these lines. > * Use C-style comments for multi-line comments, and C++-style comments > for single-line comments. I'm not sure i agree with this, because I don't see anything wrong with multi-line C++-style comments. Ian
Re: Using C++ in GCC is OK
> I did mean that all virtual functions should be protected. This forbids the most useful thing about virtual functions - letting child classes implement a public ABI defined by the base class. > > * All data members should be private. > > * All data members should have names which end with an underscore. > > > > This makes all structures illegal. I'd remove the first "All" and > > replace the second with "Private": > > This text only refers to classes. As the convention says in the > following major bullet, structs are handled as they are today. I don't agree that *all* data members of classes should be private. It's not always appropriate - it depends on the design of the class. I'd hate to be forced to do this for every datum: int count; int get_count (); void set_count (int); That gets messier when the datum are pointers. foo->bounds->left is cleaner than foo->get_bounds()->get_left(). > Our current code always uses the equivalent of an explicit this > pointer, except that it is called something else. Our current code is also written in C, and we're trying to move away from that limitation... > The biggest need for this-> is when calling methods in the current > class if the current class happens to be in a template. I generally avoid classes-in-templates. That road leads to confusion pretty easily. If a design *requires* a "this->", I'd say the design is defective and the code should be rewritten. > > * Use C-style comments for multi-line comments, and C++-style comments > > for single-line comments. > > I'm not sure i agree with this, because I don't see anything wrong > with multi-line C++-style comments. It assumes your editor can do block-reformatting while preserving the comment syntax. I've had too many // cases of Emacs guessing wrong // and putting // throughout a reformatted // block.
Re: Using C++ in GCC is OK
On 1 June 2010 22:13, Ian Lance Taylor wrote: > DJ Delorie writes: > >> My suggestions: >> >> * When it is appropriate to use a child class with virtual functions, >> the virtual functions should all be declared as protected in the >> parent class. >> >> At first reading, I thought you meant "all virtual functions should be >> protected", but I think you meant "if a child ADDS a virtual function >> that the parent doesn't have, ...", but in that case I don't see why the >> parent needs a declaration at all. This should be clarified. > > I did mean that all virtual functions should be protected. I tried to > clarify the wiki page. If a reference helps, this is sometimes referred to as the Non-Virtual Interface or NVI idiom: http://www.gotw.ca/publications/mill18.htm (I've also heard it called, IIRC, the Non-Useful Interface idiom, but nevermind!) >> * All data members should be private. >> * All data members should have names which end with an underscore. >> >> This makes all structures illegal. I'd remove the first "All" and >> replace the second with "Private": > > This text only refers to classes. As the convention says in the > following major bullet, structs are handled as they are today. Nothing in C++ prevents a "struct" from having member functions, constructors, base classes, virtual functions, private members etc. If the intention is to impose a distinction between structs and classes, based on which keyword is used to define the type, the convention should say so. (FWIW, I think that's a reasonable convention for a codebase that originated as pure C.) > Our current code always uses the equivalent of an explicit this > pointer, except that it is called something else. Therefore I would > argue that this is not new. I don't see why using an explicit this-> > makes code harder to understand in a larger scope; the explicit this-> > makes it very clear where data is coming from. If data members have a trailing underscore then isn't it already explicit where an unqualified name comes from? foo_ must refer to this->foo_, while p->foo_ obviously refers to p's foo_. > The biggest need for this-> is when calling methods in the current > class if the current class happens to be in a template. The 'this->' is needed when the current class and base class are both templates and the name is declared in the base class, and not if it's declared in the current class. That is not likely to happen in a hurry while the convention is to not define any templates. > The C++ template namespace lookup rules are confusing. If I understand the problem you're referring to, namespaces are not involved. Only base classes whose complete type depends on a template parameter. Just to try and avoid further confusion! > The explicit this-> > makes them clear. While it's true that most code is not in a > template, it's possible that a template will be added later. > > I'm not going to fight to the death on this one, and I would be > interested in hearing other opinions. I've been using explicit this-> > in my own C++ code for many years, and I find that it clarifies rather > than confuses. There are cases where "this->" can't be used (e.g. referring to a type defined in a dependent base, there's an example on p138 in C++ Templates by Vandevoorde and Josuttis) so it might not be appropriate to require it always, even when it's not needed. >> * Local variables should be declared where they're first used, if their >> use is contiguous and localized. If they're ubiquitous (like a return >> value temporary) or reused later (like "i" for for-loop iterators), >> declare them at the beginning of the function. > > Thanks, I added text along these lines. C++ for-loop scoping means there is no need to reuse the loop variable unless you explicitly want to preserve the same value across loops. Is the intention to avoid relying on C++ for-loop scoping? If so, that should be stated. >> * Use C-style comments for multi-line comments, and C++-style comments >> for single-line comments. > > I'm not sure i agree with this, because I don't see anything wrong > with multi-line C++-style comments. Me neither, but I work in C++ every day, so I'm obviously not a good judge of what others will be comfortable with.
RE: Using C++ in GCC is OK
> > My suggestions: > > > > * When it is appropriate to use a child class with virtual > functions, > >the virtual functions should all be declared as protected in the > >parent class. > > > > At first reading, I thought you meant "all virtual functions should > be > > protected", but I think you meant "if a child ADDS a virtual function > > that the parent doesn't have, ...", but in that case I don't see why > the > > parent needs a declaration at all. This should be clarified. > > I did mean that all virtual functions should be protected. I tried to > clarify the wiki page. Is "do not introduce new virtual functions in a child class" another way to phrase this? > > * Namespaces > > > > In general, I don't like namespaces, unless you're defining a > package. > > Class names create their own name spaces, globals should be global, > etc. > > Saying "everything should be in a namespace" is IMHO an inappropriate > > restriction. Indicate where namespaces are appropriate, leave it at > > that. > > The proposal doesn't say that everything should be in a namespace; it > says that namespaces are permitted. I continue to think that is > appropriate. I agree that globals should be global. However, GCC is > a big package which can be naturally divided into modules. For > example, GIMPLE code should not normally call RTL functions. Putting > the RTL functions in a namespace would make it clear when something is > reaching across a module boundary. Of course there are other ways to > do this as well, but my point is that "global is global" is not > necessary a well-defined concept in a big program. Some names are > global to parts of the program but not to others. I agree. In my experience, people can often lean too heavily on namespaces to help them avoid silent collisions of implementation that would otherwise be avoided by more carefully monitoring and maintaining header file dependencies. > > * When a method refers to a non-static data member, it should always > >qualify the reference with this->. > > > > I'm very opposed to this. To me, it makes the code less readable > > because it lets the author write code that's hard to understand at a > > larger scope. I would forbid explicit references to "this" except to > > pass it unadorned as a parameter to some other function. If it's not > > clear where method call data comes from, write clearer code! > > > > If you're implementing a class, it should be clear you're > implementing a > > class, and implied that data/methods come from the class unless > > specified otherwise (which you'd have to do anyway, like foo- > >reg_p()). > > If it's not clear, you've not properly encapsulated the class and you > > need to redesign it so it *is* properly contained and easy to > > understand. > > Our current code always uses the equivalent of an explicit this > pointer, except that it is called something else. Therefore I would > argue that this is not new. I don't see why using an explicit this-> > makes code harder to understand in a larger scope; the explicit this-> > makes it very clear where data is coming from. > > The biggest need for this-> is when calling methods in the current > class if the current class happens to be in a template. The C++ > template namespace lookup rules are confusing. The explicit this-> > makes them clear. While it's true that most code is not in a > template, it's possible that a template will be added later. For methods, I understand and agree. Does this still hold up for non-static data members which by previous guidelines are highly recommended to be private, though? If not, would the recommendation for always qualifying the reference just to be for consistency? I'm leaning toward DJ's opinion on this one, mainly because it is somewhat duplicative. Also, requiring data members to end in an underscore expresses the scope already. but I can see where you're coming from as well. > > * use of existing templates, e.g., from the standard library, is > fine > > > > I'd prefer avoiding pulling in STL stuff at first. I find STL to be > > quite a "culture shock" relative to C. When used I'd limit it to one > > STL object at a time - avoid containers of lists of vectors of > strings, > > etc. > > As noted earlier I think we do want to use some STL classes. I agree with Mark's earlier declaration that it is relatively straight-forward, low-hanging fruit to replace VEC_* with std::vector. (I had started trying this replacement myself last year, but the CXX build on trunk without any changes never did bootstrap and pass the testsuite correctly for me on Ubuntu 9.10, so I couldn't easily test my changes.) > > * Local variables should be declared where they're first used, if > their > > use is contiguous and localized. If they're ubiquitous (like a > return > > value temporary) or reused later (like "i" for for-loop iterators), > > declare them at the beginning of the function. > > Than
gcc-4.4-20100601 is now available
Snapshot gcc-4.4-20100601 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100601/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 160125 You'll find: gcc-4.4-20100601.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100601.tar.bz2 C front end and core compiler gcc-ada-4.4-20100601.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100601.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100601.tar.bz2 C++ front end and runtime gcc-java-4.4-20100601.tar.bz2 Java front end and runtime gcc-objc-4.4-20100601.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100601.tar.bz2The GCC testsuite Diffs from 4.4-20100525 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Using C++ in GCC is OK
On 01/06/2010 22:13, Ian Lance Taylor wrote: >> * When a method refers to a non-static data member, it should always >>qualify the reference with this->. >> >> I'm very opposed to this. To me, it makes the code less readable >> because it lets the author write code that's hard to understand at a >> larger scope. I would forbid explicit references to "this" except to >> pass it unadorned as a parameter to some other function. If it's not >> clear where method call data comes from, write clearer code! >> >> If you're implementing a class, it should be clear you're implementing a >> class, and implied that data/methods come from the class unless >> specified otherwise (which you'd have to do anyway, like foo->reg_p()). >> If it's not clear, you've not properly encapsulated the class and you >> need to redesign it so it *is* properly contained and easy to >> understand. >> DJ never refers to himself in the third person, I don't see why his code >> should. > > Our current code always uses the equivalent of an explicit this > pointer, except that it is called something else. Therefore I would > argue that this is not new. I don't see why using an explicit this-> > makes code harder to understand in a larger scope; the explicit this-> > makes it very clear where data is coming from. > > The biggest need for this-> is when calling methods in the current > class if the current class happens to be in a template. The C++ > template namespace lookup rules are confusing. The explicit this-> > makes them clear. While it's true that most code is not in a > template, it's possible that a template will be added later. > > I'm not going to fight to the death on this one, and I would be > interested in hearing other opinions. I've been using explicit this-> > in my own C++ code for many years, and I find that it clarifies rather > than confuses. In a project with as many globals as we have, it's kinda handy to know at a glance whether a member function is accessing a data member or a global. But if we follow the data-members-must-end-with-an-underscore convention, that would convey the same information. So I'd be happy with either one of those two, and using both would seem overkill. cheers, DaveK
Re: Using C++ in GCC is OK
> In a project with as many globals as we have, it's kinda handy to > know at a glance whether a member function is accessing a data > member or a global. Add a globals-in-namespaces rule, or a ::global syntax, and you have even more overkill. IMHO we should make it easy to implement a clean design, and hard to implement a poor one. Use the extra syntax on the cases we want to discourage (cross-module references, non-namespace-globals, etc) and leave the desirable designs (well-contained code, modularization) with the simpler syntax.
RE: Using C++ in GCC is OK
A suggestion about: "Method bodies may only appear in the class definition if they are very short, no more than five lines. Otherwise the method body should be defined outside of the class definition." To avoid dependency explosions that increase compile times and allow for link-time substitutability, I would suggest that method bodies should very rarely appear in header files. In my experience, this dramatically improves the likelihood that complex and/or user-defined types can be forward-declared and therefore can improve encapsulation and lower compilation times. This is also critical for link-time injection of mocks for unit testing, which is often the first step when transitioning a non-OO codebase toward OO. Classically, the main reason to put small functions into header files was to allow for inlining of small functions. With LTO, this point should be somewhat moot. In our internal testing of mega-compilation (a poor man's LTO where source files for a given binary module are #included into a single compilation unit), clearing header files of almost all method bodies resulted in a 20% decrease in compilation times and an 11% performance improvement at the system level. These improvements were icing on the cake, as our primary goal was to improve unit-testability by way of better encapsulation (and other OO principles).
Re: merging the maverick FPU patches
On 4/25/10, Ian Lance Taylor wrote: > Martin Guy writes: > > > now that stage3 is over I'm thinking of updating the > > MaverickCrunch FPU fixes (currently for 4.3) and merging them but > > would appreciate some guidance. > > > > There are 26 patches in all and I can't expect anyone to understand > > them because they require a good understanding of the FPU and its > > hardware bugs (and there are a lot of them!) :) What's the best path? > > Create a branch, work there and then merge when done? > > > > I have done the copyright assignment stuff but don't have an account > > on gcc.gnu.org. They all affect files under config/arm/ apart from one > > testsuite fix and the docs. > > > For a backend specific patch like this, I would recommend contacting > the ARM backend maintainers directly to ask how they would prefer to > proceed. They can be found in the top level MAINTAINERS file: > > arm portNick Cliftonni...@redhat.com > arm portRichard Earnshawrichard.earns...@arm.com > arm portPaul Brook p...@codesourcery.com Hi I've had no reply from anyone - maybe everyone is hoping someone else do so. :) Of the three companies, redhat would be the most suitable, since the original unfinished port was done by them, and I guess ARM has no interest in making GCC work with non-ARM FPUs. The code they add/remove/change is pretty self-contained and doesn't impact the other code generation options. It just fixes the current implementation. Nick, are you willing to do the necessary? Since it just fixes existing code that never worked, all it requires from a maintainer is to check that it doesn't break code generation for other targets, which is easy to check automatically by testing a sample of targets and it's not hard to check by eye that the changes are only active when TARGET_MAVERICK. Cheers M
GFDL/GPL Issue
As I mentioned last week, I've been talking to the SC and RMS about the issue of automatically generating GFDL'd documentation from GPL'd code. I will state explicitly up front a few topics I am not raising, because I do not think they are either necessary, or likely to be productive: * Whether or not the GFDL is a "free" license, or whether it's a good license, or anything else about its merits or lack thereof * Whether we can take things out of the current GFDL manuals and put them into GPL'd code The first is immaterial from the limited perspective of trying to figure out how to make it possible for us to make better (in terms of content) manuals more easily. The second issue *is* relevant, in that we might want to bring some of what's currently in manuals into the code, but I think it's less important than the question of whether we can auto-generate manuals from code on a going-forwards basis. And, it's simpler to work on one thing at a time. At this point, RMS has said, answered this question from me: "Can we take comments (not code) from FSF-owned GPL'd code and process them in some way that results in them being included in a GFDL'd manual?" by saying, in part: "If Texinfo text is included the .h files specifically to be copied into a manual, it is ok to for you copy that text into a manual and release the manual under the GFDL." In context, "you" means "the GCC maintainers" and the permission would be limited only to changes contributed to the FSF. This is specifically not permission for random people to do even this outside the context of the FSF repository. RMS acknowledges that this is a problem, but he says (and I agree) that we would need a GPL license exception to make this a fully general permission, and he says that will take a long time. This limited permission might be enough to solve some problems. For example, we could write TeXinfo in special comments for hooks, and have some script that pulled out the comments and generated a TeXinfo document listing all the hooks. But, it doesn't help with things more like Javadoc or Doxygen or Synopsis. (Disclosure: Stefan Seefeld, one of my fellow Sourcerers is the lead author of Synopsis.) These tools can parse the code, creating cross-references of various kinds, while also extracting documentation intended for users of the API. So, my question is this: is the permission above sufficient for what people want to do at this point? Or do we need more? And if we need more (as I suspect), can we be specific about what toolflow we want to follow and what content will be generated? It would help if I could show RMS inputs and outputs, not just with some random example, but with GCC itself. Is someone willing to apply enough effort to produce at least some fragments of documentation using some method, and document that method for me, so that I can provide it to RMS. (An obvious strategy generate these manuals under the GPL, rather than the GFDL, thereby dodging the issue. But, RMS does not want GCC having GPL'd manuals. Maybe if we show him what we want to do, he will conclude that GPL'd manuals are an acceptable outcome, and easier than trying to do license exceptions.) Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
DJ Delorie writes: >> I did mean that all virtual functions should be protected. > > This forbids the most useful thing about virtual functions - letting > child classes implement a public ABI defined by the base class. There are really two cases to consider, and actually the coding standard should describe this. 1) The parent class consists only of pure virtual methods. In that case it is perfectly reasonable for those methods to be public. 2) The parent class does not consist only of pure virtual methods. In that case I am arguing that all virtual methods should be protected. In cases where the virtual method implements something which is part of the public interface, there should be a public method which calls the protected method. The reason for the latter case is that the parent class is providing a public interface, and it is doing so by using a separate interface defined by child classes. The two interfaces are obviously related, but they are not the same. In particular, as new child classes are implemented and the parent class interface evolves, they evolve in different ways. Keeping the two interfaces separate from the start avoids confusion and makes it easy to redesign either interface separately from the other one. >> > * All data members should be private. >> > * All data members should have names which end with an underscore. >> > >> > This makes all structures illegal. I'd remove the first "All" and >> > replace the second with "Private": >> >> This text only refers to classes. As the convention says in the >> following major bullet, structs are handled as they are today. > > I don't agree that *all* data members of classes should be private. > It's not always appropriate - it depends on the design of the class. > I'd hate to be forced to do this for every datum: > > int count; > int get_count (); > void set_count (int); > > That gets messier when the datum are pointers. foo->bounds->left is > cleaner than foo->get_bounds()->get_left(). I think I'm advocating a reasonable position here. With our current data structures such as tree and rtx, we generally do not use direct field access, but always use accessors. For cases where direct field access is appropriate can use structs. What do other people think? >> > * Use C-style comments for multi-line comments, and C++-style comments >> > for single-line comments. >> >> I'm not sure i agree with this, because I don't see anything wrong >> with multi-line C++-style comments. > > It assumes your editor can do block-reformatting while preserving the > comment syntax. I've had too many // cases of Emacs guessing wrong // > and putting // throughout a reformatted // block. I don't see why the coding standard should prohibit using a good editor, but I'm willing to hear what other people think. Ian
Re: [Bug rtl-optimization/44013] VTA produces wrong code
On Jun 1, 2010, Hariharan wrote: > I have not had any response from Alexandre on this yet Sorry, been on vacations, started looking into it last night, I think I know why it fails and how to fix it. Expect a patch soon. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: Using C++ in GCC is OK
Jonathan Wakely writes: > Nothing in C++ prevents a "struct" from having member functions, > constructors, base classes, virtual functions, private members etc. > If the intention is to impose a distinction between structs and > classes, based on which keyword is used to define the type, the > convention should say so. (FWIW, I think that's a reasonable > convention for a codebase that originated as pure C.) Well, the convention does in fact say so. But it's true that I didn't write whether we should permit structs to have methods. I'm inclined to say no. >> Our current code always uses the equivalent of an explicit this >> pointer, except that it is called something else. Therefore I would >> argue that this is not new. I don't see why using an explicit this-> >> makes code harder to understand in a larger scope; the explicit this-> >> makes it very clear where data is coming from. > > If data members have a trailing underscore then isn't it already > explicit where an unqualified name comes from? foo_ must refer to > this->foo_, while p->foo_ obviously refers to p's foo_. Granted. >> The biggest need for this-> is when calling methods in the current >> class if the current class happens to be in a template. > > The 'this->' is needed when the current class and base class are both > templates and the name is declared in the base class, and not if it's > declared in the current class. That is not likely to happen in a > hurry while the convention is to not define any templates. Right, but it may happen some day. Also there is the issue of clarity. I think it is clearer to see this->get() rather than get(). > C++ for-loop scoping means there is no need to reuse the loop variable > unless you explicitly want to preserve the same value across loops. > Is the intention to avoid relying on C++ for-loop scoping? If so, > that should be stated. I don't think that should be the intention. Ian
Re: Using C++ in GCC is OK
On 06/02/2010 01:42 AM, Ian Lance Taylor wrote: >> The 'this->' is needed when the current class and base class are both >> templates and the name is declared in the base class, and not if it's >> declared in the current class. That is not likely to happen in a >> hurry while the convention is to not define any templates. > > Right, but it may happen some day. Also there is the issue of > clarity. I think it is clearer to see this->get() rather than get(). gold is using this convention, isn't it? I think there's value in using similar or even identical conventions for both gold and gcc so that people hacking both don't need to learn two different sets. Bernd
Re: Using C++ in GCC is OK
> 2) The parent class does not consist only of pure virtual methods. > In that case I am arguing that all virtual methods should be > protected. What about the case where the parent provides default implementations of methods that are infrequently overridden by children? Otherwise, you end up with cases where every child class needs to implement every virtual method, whether it needs to for its own purposes or not. Your proposal forbids the case where a child is just like the parent, "except that this method is a little different...", which describes a lot of useful heirarchies. The gcc example would be the RTL base class defining RTL::reg_p() to return false, and having the one class that is a reg redefine it to return true. > The reason for the latter case is that the parent class is providing > a public interface, and it is doing so by using a separate interface > defined by child classes. The two interfaces are obviously related, Maybe you and I have completely different ideas about how the whole class heirarchy works. I'm not a firm believer that the base-most class should be an empty shell of a class that does nothing but provide a placeholder for umpteen direct-but-leaf derived classes. A base class is simply a more generic representation of data (and may be derived from something even more generic), and derived classes are more specific representations (and may be inherited by even more specific representations). > there should be a public method which calls the protected method. I suggest this is arbitrary and unneeded. Having a foo_public() that just calls foo_protected() is a waste of time (and means you have to come up with two unique names for the same function), just move the foo() into the public space. > In particular, as new child classes are implemented and the parent > class interface evolves, they evolve in different ways. Keeping the > two interfaces separate from the start avoids confusion and makes it > easy to redesign either interface separately from the other one. I recognize that there's an API between the classes and the rest of the world, and a separate API between a base class and its children. I disagree that we should force any given class to have one or the other but not both. > I don't see why the coding standard should prohibit using a good > editor, but I'm willing to hear what other people think. It's not about prohibiting a good editor, it's about prohibiting a not-as-good-as-yours editor.
Re: Using C++ in GCC is OK
> Right, but it may happen some day. Also there is the issue of > clarity. I think it is clearer to see this->get() rather than get(). this->put_size (this->get_bounds (this->get_x(), this->get_y()), this->get_variance (this->default_variance ())) I'd like to avoid needing to assign "this->" to a hotkey in emacs.
Re: Using C++ in GCC is OK
> gold is using this convention, isn't it? I find the gold sources harder to read than the rest of binutils, and would like to avoid propogating that style elsewhere. This from someone who's been writing C++ code for twenty years now. Also, gold was added to binutils without this type of discussion about what C++ style should be used for a formerly-C project, so please don't use it as an example of The Right Thing To Do.
Re: GFDL/GPL Issue
Quoting Mark Mitchell : At this point, RMS has said, answered this question from me: "Can we take comments (not code) from FSF-owned GPL'd code and process them in some way that results in them being included in a GFDL'd manual?" We also need struct member declarations. I.e type and name. In the case of function members - as is common with hooks - that includes return type and the types of all arguments; moreover, we also want the names of the function arguments. As we move to C++, that might morph to class members / member functions. So, my question is this: is the permission above sufficient for what people want to do at this point? Or do we need more? And if we need more (as I suspect), can we be specific about what toolflow we want to follow and what content will be generated? It would help if I could show RMS inputs and outputs, not just with some random example, but with GCC itself. Is someone willing to apply enough effort to produce at least some fragments of documentation using some method, and document that method for me, so that I can provide it to RMS. See: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02255.html Search for GPL and/or GFDL for a sample of things that we currently can't fix due to licensing issues.
Re: GFDL/GPL Issue
Joern Rennecke wrote: >> And if we need >> more (as I suspect), can we be specific about what toolflow we want to >> follow and what content will be generated? It would help if I could >> show RMS inputs and outputs, not just with some random example, but with >> GCC itself. Is someone willing to apply enough effort to produce at >> least some fragments of documentation using some method, and document >> that method for me, so that I can provide it to RMS. > > See: > http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02255.html OK, I see what that is doing. Why did you choose to use a .def file rather than something more like Doxygen to generate the documentation? Consistency with existing practice of .def files in GCC? Or you don't like Doxygen-like tools? Or something else? (I'm not making a judgment here, but I need to understand why so that I can explain things to RMS.) > Search for GPL and/or GFDL for a sample of things that we currently > can't fix due to licensing issues. I'm happy to act as an advocate, but I don't have the time to do a lot of research. Would you please describe the steps and provide the inputs and outputs of the process for some of these issues? I want to able to show RMS an actual input file, an actual output file, and describe the transformation process that leads from one to the other. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 7:00 PM, Bernd Schmidt wrote: > On 06/02/2010 01:42 AM, Ian Lance Taylor wrote: >>> The 'this->' is needed when the current class and base class are both >>> templates and the name is declared in the base class, and not if it's >>> declared in the current class. That is not likely to happen in a >>> hurry while the convention is to not define any templates. >> >> Right, but it may happen some day. Also there is the issue of >> clarity. I think it is clearer to see this->get() rather than get(). > > gold is using this convention, isn't it? I think there's value in using > similar or even identical conventions for both gold and gcc so that > people hacking both don't need to learn two different sets. yes, but: (1) I suspect the community hacking GCC may be larger that the community hacking gold (2) I do not remember there was an extensive discussion about the style used in gold (3) you may be right about commonality in styles for both GCC and gold, but that does not imply that whatever was decided for gold has to be adopted straight by the GCC community. As I matter of fact, I have comments about the conventions being put forward, I do not know the proper way to get them reflected in the proposal. There are lot of FUDs out there about what or what not to use (from C++). We should be careful in not giving them more food that they already have.
Re: Using C++ in GCC is OK
"Hargett, Matt" writes: >> As noted earlier I think we do want to use some STL classes. > > I agree with Mark's earlier declaration that it is relatively > straight-forward, low-hanging fruit to replace VEC_* I do not object to simple and obvious uses of STL to replace equivalent functionality, but I've seen code that layers STL over STL over STL to the point where the code is very difficult to understand. Hence, my recommendation to avoid STL *at first*. It teaches caution against over-abstracting and arbitrary complexity. >> I'm not sure i agree with this, because I don't see anything wrong >> with multi-line C++-style comments. > > I'm with Ian on this one. Is there a reason for this, other than one's > personal tool preference for editing code may make C-style multi-line > comments easier to add/remove? Anything that makes comments harder to maintain, I'm against. But there's a grey area for 2-5 line comments preceeding a line of code, for example. I'd really hate to see 50 lines of formatted paragraphs and diagrams, each with "//" at the beginning, when a single /* at the beginning and */ at the end would do just as well and avoid decorating every single line of what is essentially documentation. Again, my goal is to encourage good practices (i.e. complete and up-to-date comments) easier to follow by giving them the easiest syntax to deal with (i.e. any editor can edit them easily, any reader can read them easily). As for personal tool preference, I prefer emacs, which is one of the editors that *can* deal with C++-style block comments, and I still want to avoid them. > In other (more sane) cases, an editor of choice has a bug in one of > its extensions that needed fixing, Or is completely lacking the language-aware extensions needed to deal with such things, but has a simple "reformat paragraph" function. Or has no such function so must be manually reformatted. > One thing I disagree with in the wiki is the complete disallowance of > multiple inheritance. Multiple inheritance is evil. IMHO class heirarchy reflects an "is-a" relationship, and one thing cannot be two things. It gets worse when the two immediate ancestors are derived from a common ancestor, and it becomes less obvious which path is taken to get to the common methods and data. If you need to add child-specific intelligence to a method, which ancestor's method do you call next to continue processing? Who calls the common ancestor? Once you've seen a heirarchy with dozens if not hundreds of members and wild multiple inheritance schemes, you'll understand.
Re: GFDL/GPL Issue
Mark Mitchell writes: > So, my question is this: is the permission above sufficient for what > people want to do at this point? This permission exactly covers what libiberty does for its documentation, you can use that as an example to RMS.
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 7:05 PM, DJ Delorie wrote: > >> Right, but it may happen some day. Also there is the issue of >> clarity. I think it is clearer to see this->get() rather than get(). > > this->put_size (this->get_bounds (this->get_x(), this->get_y()), > this->get_variance (this->default_variance ())) > > I'd like to avoid needing to assign "this->" to a hotkey in emacs. > I agree that the "this->" is overly rigid. FWIW, we already have C++ style in the GCC distribution -- see libstdc++. Not all of it has to be imported (for example, the uglification stuff makes no sense.)
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 7:03 PM, DJ Delorie wrote: > Maybe you and I have completely different ideas about how the whole > class heirarchy works. I'm not a firm believer that the base-most > class should be an empty shell of a class that does nothing but > provide a placeholder for umpteen direct-but-leaf derived classes. I would recommend against the idea that the root class of a hierarchy shall be empty -- except if it is an interface, e.g. an abstract class.
Re: Using C++ in GCC is OK
On 06/01/10 17:42, Ian Lance Taylor wrote: The biggest need for this-> is when calling methods in the current class if the current class happens to be in a template. The 'this->' is needed when the current class and base class are both templates and the name is declared in the base class, and not if it's declared in the current class. That is not likely to happen in a hurry while the convention is to not define any templates. Right, but it may happen some day. Also there is the issue of clarity. I think it is clearer to see this->get() rather than get(). Agreed.For me at least, that style is far easier to read and understand. It's very clear what "get" means. Jeff
C++ vs Cpp v Cxx
Can we make a point of not using "Cpp" as a normalization of "C++" ? I keep thinking it's referring to the C preprocessor. "Cxx" is less misleading (and kinda looks the same), when "C++" cannot be used for character set reasons.
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie wrote: > > "Hargett, Matt" writes: >>> As noted earlier I think we do want to use some STL classes. >> >> I agree with Mark's earlier declaration that it is relatively >> straight-forward, low-hanging fruit to replace VEC_* > > I do not object to simple and obvious uses of STL to replace equivalent > functionality, but I've seen code that layers STL over STL over STL to > the point where the code is very difficult to understand. Hence, my > recommendation to avoid STL *at first*. I think that would be most unproductive and misguided. The first thing we should do is (1) resist NIH Then (2) we should prefer standard solution over home-grown hacks, unless there is a clear demonstration of value. For example, it would be unwise to prefer our current VEC_xxx over std::vector. Conversely, we should probably have our own hash table, since there is none in C++98. > It teaches caution against over-abstracting and arbitrary complexity. avoiding over-abstracting is not reached by banning standard solutions -- that only lead to more brittle and bug-ridden hacks. The way we avoid over-abstracting is to have people write simple codes, and reviewers use their best judgments.
Re: C++ vs Cpp v Cxx
On Tue, Jun 1, 2010 at 7:47 PM, DJ Delorie wrote: > > Can we make a point of not using "Cpp" as a normalization of "C++" ? strongly seconded. > I keep thinking it's referring to the C preprocessor. Same here. > "Cxx" is less > misleading (and kinda looks the same), when "C++" cannot be used for > character set reasons. > agreed.
Re: GFDL/GPL Issue
Quoting Mark Mitchell :
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02255.html
OK, I see what that is doing. Why did you choose to use a .def file
rather than something more like Doxygen to generate the documentation?
It is not only used to generate documenation, but also to generate
initializers for all the struct gcc_target members. While at the same
time serving as an include file for target.h .
Also, the documentation generation allows the generation of @findex
statements by using @fcode instaed of @code, and places these @findex
statements at the start of the enclosing paragraph; however, this part
is
not really introducing any extra licensing issues, and describing the
operation in detail would probably be distracting.
Search for GPL and/or GFDL for a sample of things that we currently
can't fix due to licensing issues.
I'm happy to act as an advocate, but I don't have the time to do a lot
of research. Would you please describe the steps and provide the inputs
and outputs of the process for some of these issues?
For a typical hook member, we got the following macro:
DEFHOOK(NAME, DOC, TYPE, PARAMS, INIT)
TYPE and PARAMS is wrapped in @var as appropriate and prepended /
appended to the capitalized NAME to give the target hook signature in
the documentation.
Also, NAME usually gets prepended with a prefix; the current prefix is
specified in separate macro in target.def.
E.g.:
DEFHOOK
(adjust_cost_2,
"Given the current cost, @var{cost}, of an insn, @var{insn}, calculate and\
return a new cost based on its relationship to @var{dep_insn} through the\
dependence of weakness @var{dw}. The default is to make no adjustment.",
int, (rtx insn, int dep_type1, rtx dep_insn, int cost, int dw), NULL)
Gives:
@deftypefn {Target Hook} int TARGET_SCHED_ADJUST_COST_2 (rtx
@var{insn}, int @var{dep_type1}, rtx @var{dep_insn}, int @var{cost},
int @var{dw})
Given the current cost, @var{cost}, of an insn, @var{insn}, calculate
and return a new cost based on its relationship to @var{dep_insn}
through the dependence of weakness @var{dw}. The default is to make
no adjustment.
@end deftypefn
Because of licensing issues, my patch so far uses DEFHOOK_UNDOC for
adjust_cost_2 instead, so that the hook remains undocumented.
I want to able to
show RMS an actual input file, an actual output file, and describe the
transformation process that leads from one to the other.
target.def is a GPLed input file, and tm.texi.in is a GFDLed input file.
tm.texi is the GFDLed output file.
If you like, I can send you the complete files in non-patch form.
Re: Using C++ in GCC is OK
> I think that would be most unproductive and misguided. Maybe I should step back and restate my original desires. I don't want us to move *too quickly* towards an all-STL implementation, and end up with a hairy mess that's hard to understand. I've had to debug our STL implementation before, it's not easy for someone not used to the design. I agree that NIH is bad. But I also think mega-patches that do nothing but replace a huge chunk of existing (working!) code with a hugely complex interaction of every STL class known to science, is equally bad. I request moderation, not abstinence. One approach to such a goal is to require that a migration limit itself to replacing one aspect of the implementation *at a time*, get that reviewed, applied, and understood, *then* migrate the next aspect, etc. Replace VEC with the STL vector class, but keep everything else around it the same. Get it reviewed. Then replace another piece and get it done. Then another, and another, etc. I also think that we'll have enough things to worry about just by switching compilers, without adding the risks associated with replacing working code. One step at a time :-)
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 8:03 PM, DJ Delorie wrote: > >> I think that would be most unproductive and misguided. > > Maybe I should step back and restate my original desires. > > I don't want us to move *too quickly* towards an all-STL > implementation, and end up with a hairy mess that's hard to > understand. I've had to debug our STL implementation before, it's not > easy for someone not used to the design. > > I agree that NIH is bad. But I also think mega-patches that do > nothing but replace a huge chunk of existing (working!) code with a > hugely complex interaction of every STL class known to science, is > equally bad. > > I request moderation, not abstinence. OK, I agree with moderation. Thanks for the elaboration. > > One approach to such a goal is to require that a migration limit > itself to replacing one aspect of the implementation *at a time*, get > that reviewed, applied, and understood, *then* migrate the next > aspect, etc. Replace VEC with the STL vector class, but keep > everything else around it the same. Get it reviewed. Then replace > another piece and get it done. Then another, and another, etc. > > I also think that we'll have enough things to worry about just by > switching compilers, without adding the risks associated with > replacing working code. One step at a time :-) > :-) -- Gaby
Re: Using C++ in GCC is OK
> > Right, but it may happen some day. Also there is the issue of > > clarity. I think it is clearer to see this->get() rather than get(). > > this->put_size (this->get_bounds (this->get_x(), this->get_y()), > this->get_variance (this->default_variance ())) I think clarity can be a mixed bag sometimes and there's a tradeoff. While in the "micro" view, one thing might be clearer than the other, if it's longer in a repetitive way (like the above), it's harmful to clarity because it keeps the eye from quickly seeing the important things since it has to "filter" out the redundancy. All of us make tradeoff like this all the time: it's why we tend to make variables that are used more be shorter. And I think the GNU Coding Conventions are designed with the above principle in mind. I don't know enough C++ to have any comments on specific issues here, but I think it important to preserve the principle that we want to have enough information in the code for the "practiced eye" to quickly see what's going on, but not enough that it make it HARDER to do that.
Re: Using C++ in GCC is OK
Bernd Schmidt writes: > On 06/02/2010 01:42 AM, Ian Lance Taylor wrote: >>> The 'this->' is needed when the current class and base class are both >>> templates and the name is declared in the base class, and not if it's >>> declared in the current class. That is not likely to happen in a >>> hurry while the convention is to not define any templates. >> >> Right, but it may happen some day. Also there is the issue of >> clarity. I think it is clearer to see this->get() rather than get(). > > gold is using this convention, isn't it? I think there's value in using > similar or even identical conventions for both gold and gcc so that > people hacking both don't need to learn two different sets. gold does use that convention, as does the gccgo frontend, but I am not advocating importing the gold style wholesale into gcc. Ian
Re: Using C++ in GCC is OK
Gabriel Dos Reis writes: > As I matter of fact, I have comments about the conventions being put forward, > I do not know the proper way to get them reflected in the proposal. As I said earlier, send e-mail here, or update the wiki page. When updating the wiki page, please put your name on all changes. Ian
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 8:41 PM, Ian Lance Taylor wrote: > Gabriel Dos Reis writes: > >> As I matter of fact, I have comments about the conventions being put forward, >> I do not know the proper way to get them reflected in the proposal. > > As I said earlier, send e-mail here, or update the wiki page. When > updating the wiki page, please put your name on all changes. OK, thanks! -- Gaby
Re: Using C++ in GCC is OK
DJ Delorie writes: >> 2) The parent class does not consist only of pure virtual methods. >> In that case I am arguing that all virtual methods should be >> protected. > > What about the case where the parent provides default implementations > of methods that are infrequently overridden by children? Otherwise, > you end up with cases where every child class needs to implement every > virtual method, whether it needs to for its own purposes or not. > > Your proposal forbids the case where a child is just like the parent, > "except that this method is a little different...", which describes a > lot of useful heirarchies. > > The gcc example would be the RTL base class defining RTL::reg_p() to > return false, and having the one class that is a reg redefine it to > return true. > >> The reason for the latter case is that the parent class is providing >> a public interface, and it is doing so by using a separate interface >> defined by child classes. The two interfaces are obviously related, > > Maybe you and I have completely different ideas about how the whole > class heirarchy works. I'm not a firm believer that the base-most > class should be an empty shell of a class that does nothing but > provide a placeholder for umpteen direct-but-leaf derived classes. A > base class is simply a more generic representation of data (and may be > derived from something even more generic), and derived classes are > more specific representations (and may be inherited by even more > specific representations). > >> there should be a public method which calls the protected method. > > I suggest this is arbitrary and unneeded. Having a foo_public() that > just calls foo_protected() is a waste of time (and means you have to > come up with two unique names for the same function), just move the > foo() into the public space. I am advocating for a particular style, in which the parent interface is rigidly separated from the child interface. That style can of course accomodate the patterns you describe, and it does not require that base-most class be an empty shell. We don't have to adopt the style I'm advocating, but let's not turn it into a strawman. You can see examples of it in action in gold and in the gccgo frontend. In general I'm thinking about programming in the large. We want to adopt a style which permits GCC to continue to grow with different people understanding different parts of the compiler. We have learned over time that this requires rigid adherence to conventions in some cases. E.g., we never access tree or rtx fields directly, and when we've done it in the past we've been sorry. From this perspective, I think arguments about simplicity are the wrong arguments. The right arguments are the ones which say that I am recommending standards which are needlessly strict, and which will not help us in keeping the GCC code base maintainable over the years. Ian
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 8:38 AM, DJ Delorie wrote: > > "Hargett, Matt" writes: >>> As noted earlier I think we do want to use some STL classes. >> >> I agree with Mark's earlier declaration that it is relatively >> straight-forward, low-hanging fruit to replace VEC_* > > I do not object to simple and obvious uses of STL to replace equivalent > functionality, but I've seen code that layers STL over STL over STL to > the point where the code is very difficult to understand. Hence, my > recommendation to avoid STL *at first*. It teaches caution against > over-abstracting and arbitrary complexity. > STL is good, but may surplus what GCC really needs, and will introduce many complex, "uncontrollable" C++ features. Personally, I think what GCC need most is an simple, generic, one layer containers of pointers to objects, with their iterators. Instead of containers of arbitrary types. That means the type parameters of the standard templates is restricted to pointer to objects. If you can't refrain from using STL and don't like the mess it may introduce, you can derive classes from instantiated standard templates with pointer as type parameters, and use the derived, template-free classes in rest of your code. And, I will be glad to see C++ strings replace all uses of C strings, but this may be hard. I don't think TREE and RTL access macros like TREE_CODE, TREE_TYPE, TREE_OPERAND, GET_CODE, GET_MODE, XEXP, etc should be replaced by virtual methods. But I think dump and debug codes may be implemented as virtual methods. -- 徐持恒(Chiheng Xu) Wuhan,China
Re: Using C++ in GCC is OK
On Jun 1, 2010, at 17:41, DJ Delorie wrote: > It assumes your editor can do block-reformatting while preserving the > comment syntax. I've had too many // cases of Emacs guessing wrong // > and putting // throughout a reformatted // block. With Ada we have no choice, and only have -- comments. I don't think I've ever encountered that kind of formatting problem, even though we definitely have active developers using Emacs. This seems a weak argument. Besides that, I don't feel strongly either way. I'd just like to avoid a mixture of // and /* */ if possible. -Geert
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 9:55 AM, 徐持恒 wrote: > On Wed, Jun 2, 2010 at 8:38 AM, DJ Delorie wrote: >> >> "Hargett, Matt" writes: As noted earlier I think we do want to use some STL classes. >>> >>> I agree with Mark's earlier declaration that it is relatively >>> straight-forward, low-hanging fruit to replace VEC_* >> >> I do not object to simple and obvious uses of STL to replace equivalent >> functionality, but I've seen code that layers STL over STL over STL to >> the point where the code is very difficult to understand. Hence, my >> recommendation to avoid STL *at first*. It teaches caution against >> over-abstracting and arbitrary complexity. >> > > STL is good, but may surplus what GCC really needs, and will introduce > many complex, "uncontrollable" C++ features. > > > Personally, I think what GCC need most is an simple, generic, one > layer containers of pointers to objects, with their iterators. > Instead of containers of arbitrary types. That means the type > parameters of the standard templates is restricted to pointer to > objects. > > > If you can't refrain from using STL and don't like the mess it may > introduce, you can derive classes from instantiated standard templates > with pointer as type parameters, and use the derived, template-free > classes in rest of your code. > The complexity of compiler determined that , in compiler, Java style C/C++ code may be unavoidable. In Java language, there are only two kinks of types, primitive types and reference types. When translated to C/C++, reference type are converted to pointer(to object) types. So, In a C/C++ program, if you only use primitive types and pointer(to object) types, I will call it Java style C/C++ code. You can use Java language to write arbitrary complex programs ? It may be true you can use Java style C/C++ code to write compiler, with some garbage collection mechanism, of course. But C/C++ may have an another advantage, it can use ADT(Abstract Data Type) to extend its set of "primitive type", e.g., string. -- 徐持恒(Chiheng Xu) Wuhan,China
Re: Using C++ in GCC is OK
On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
> (2) we should prefer standard solution over home-grown hacks, unless
> there is a clear demonstration of value. For example, it would be
> unwise to prefer our current VEC_xxx over std::vector. Conversely,
> we should probably have our own hash table, since there is none in
> C++98.
I am not entirely convinced of that. VEC is supported not only by
infamous vec.h macros (which we surely want to replace by some template,
possibly std::vec) but also by gengtype (and the Gcc Garbage Collector).
I strongly believe we will need a garbage collector (perhaps improving
the current one). So we surely will continue to need garbage collected
vectors (with all the variants existing in today's GCC).
How would we handle these in a C++ GCC? I have no clear ideas on that
today. Perhaps we might
a. have our own vector template which is almost exactly like std::vector
but named differently except that it is specially supported by GGC &
gengtype.
b. add special annotations (maybe attributes or pragmas or GTY macros
invocations or something else...) inside the code of the definition of
std::vec template (perhaps inside libstdc++-v3/include/std/vector) to
add GTY support. However, this makes our compiler less able to use some
other's vendor std::vec
c. add special annotations on every use of our vectors. BTW, this is
what our current practice of vec.h already do.
But still I don't understand how precisely we would have garbage
collected vectors, or vectors of garbage collected pointers. We need
them.
And if possible, the solution should be generic enough to work for any
other standard C++ container (i.e. maps, ...).
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: Using C++ in GCC is OK
On Tue, 2010-06-01 at 19:43 -0500, Gabriel Dos Reis wrote:
> On Tue, Jun 1, 2010 at 7:03 PM, DJ Delorie wrote:
>
> > Maybe you and I have completely different ideas about how the whole
> > class heirarchy works. I'm not a firm believer that the base-most
> > class should be an empty shell of a class that does nothing but
> > provide a placeholder for umpteen direct-but-leaf derived classes.
>
> I would recommend against the idea that the root class of a hierarchy
> shall be empty -- except if it is an interface, e.g. an abstract class.
Does a root class with only abstract virtual methods would be acceptable
for you? That would add only a vtable.
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: Using C++ in GCC is OK
> But C/C++ may have an another advantage, it can use ADT(Abstract Data > Type) to extend its set of "primitive type", e.g., string. > But C++ may have an another advantage, it can use ADT(Abstract Data Type) to extend its set of "primitive type", e.g., string. -- 徐持恒(Chiheng Xu) Wuhan,China
Re: Tree Browser
Hi, Try using gcc-vcg-plugin to browse tree and cfg during debug gcc. It's just an initial version for now. Any suggestions will be appreciated. :-) http://code.google.com/p/gcc-vcg-plugin/ Thanks, Eric Fisher
gc-improv merge plan (will need trunk freeze)
Hello all - All the patches from gc-improv merge have been approved. Due to the scope of the changes, the merge will need trunk freeze. Thus I am planning to do it next Tuesday, at 7am CEST. The freeze should last about 2-3 hours. Alternatively I could also do the merge tomorrow at the same time, but I cannot give the 48h notice then. So unless I get a green light for tomorrow's merge, the next Tuesday it is. Here is the overview of the branch: http://gcc.gnu.org/ml/gcc/2010-04/msg00414.html Cheers, -- Laurynas
Re: Using C++ in GCC is OK
Basile Starynkevitch writes:
> On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
>> (2) we should prefer standard solution over home-grown hacks, unless
>> there is a clear demonstration of value. For example, it would be
>> unwise to prefer our current VEC_xxx over std::vector. Conversely,
>> we should probably have our own hash table, since there is none in
>> C++98.
>
> I am not entirely convinced of that. VEC is supported not only by
> infamous vec.h macros (which we surely want to replace by some template,
> possibly std::vec) but also by gengtype (and the Gcc Garbage Collector).
As you say, gengtype includes specific support for VEC. Using
std::vector instead will require some work in gengtype, but not too
much. Currently gengtype generates code like this for a VEC:
size_t l0 = (size_t)(((*x).base).num);
for (i0 = 0; i0 != l0; i0++) {
if ((*x).base.vec[i0].jump_functions != NULL) {
It should be entirely feasible to make it generate std::vector
accessor functions instead.
Ian
Re: Using C++ in GCC is OK
2010/6/2 Basile Starynkevitch : > I am not entirely convinced of that. VEC is supported not only by > infamous vec.h macros (which we surely want to replace by some template, > possibly std::vec) but also by gengtype (and the Gcc Garbage Collector). > > I strongly believe we will need a garbage collector (perhaps improving > the current one). So we surely will continue to need garbage collected > vectors (with all the variants existing in today's GCC). > > How would we handle these in a C++ GCC? I have no clear ideas on that > today. Perhaps we might > See http://gcc.gnu.org/wiki/gcc-in-cxx , section "Major TODO": work out the details of using STL containers with GC allocated objects. This means teaching gengtype how to generate code to traverse STL containers, which would then be used during GC. This is not a task for the faint-hearted. Basically we can teach gengtype to walk std::vector. But I don't see how we can avoid dependency in gengtype on vector internal structures (_M_impl) and similar, and if that would not preclude building gcc with 3rd party standard library (which would be a real concern). > c. add special annotations on every use of our vectors. BTW, this is > what our current practice of vec.h already do. We can make gengtype recognize std::vector variables even without GTY annotations. -- Laurynas
Re: Using C++ in GCC is OK
2010/6/2 Ian Lance Taylor :
> As you say, gengtype includes specific support for VEC. Using
> std::vector instead will require some work in gengtype, but not too
> much. Currently gengtype generates code like this for a VEC:
>
> size_t l0 = (size_t)(((*x).base).num);
> for (i0 = 0; i0 != l0; i0++) {
> if ((*x).base.vec[i0].jump_functions != NULL) {
>
> It should be entirely feasible to make it generate std::vector
> accessor functions instead.
Ian, do you have an idea on how to avoid _M_impl dependency in
gengtype or what else to do about it?
Because we can trivially make gengtype mark the vector itself and mark
whatever was put into vector, but not _M_impl.
--
Laurynas
Re: Using C++ in GCC is OK
Laurynas Biveinis writes:
> 2010/6/2 Ian Lance Taylor :
>> As you say, gengtype includes specific support for VEC. Using
>> std::vector instead will require some work in gengtype, but not too
>> much. Currently gengtype generates code like this for a VEC:
>>
>> size_t l0 = (size_t)(((*x).base).num);
>> for (i0 = 0; i0 != l0; i0++) {
>> if ((*x).base.vec[i0].jump_functions != NULL) {
>>
>> It should be entirely feasible to make it generate std::vector
>> accessor functions instead.
>
> Ian, do you have an idea on how to avoid _M_impl dependency in
> gengtype or what else to do about it?
>
> Because we can trivially make gengtype mark the vector itself and mark
> whatever was put into vector, but not _M_impl.
I don't think I understand the question. _M_impl is a field of the
vector itself. It's not allocated separately.
Ian
Re: Using C++ in GCC is OK
2010/6/2 Ian Lance Taylor : >> Ian, do you have an idea on how to avoid _M_impl dependency in >> gengtype or what else to do about it? >> >> Because we can trivially make gengtype mark the vector itself and mark >> whatever was put into vector, but not _M_impl. > > I don't think I understand the question. _M_impl is a field of the > vector itself. It's not allocated separately. But the _M_impl._M_start is allocated separately. -- Laurynas
