* Switching to C++ by default in 4.8 @ 2012-04-03 17:38 Diego Novillo 2012-04-03 19:39 ` Paweł Sikora ` (2 more replies) 0 siblings, 3 replies; 182+ messages in thread From: Diego Novillo @ 2012-04-03 17:38 UTC (permalink / raw) To: gcc; +Cc: Ian Lance Taylor, Lawrence Crowl We would like to start the process to make GCC 4.8 build in C++ mode by default. The mechanics of the change are simple enough. I volunteer to test changing the default on all primary targets (assuming I can get them from the GCC build farm). Concurrently with this, Lawrence and Ian are working on the C++ coding guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions. They will be sending an update in the next few days. The idea is to hash out the details on the wiki and then produce a patch to http://gcc.gnu.org/codingconventions.html. While these two changes are independent, it probably makes sense to first have agreement on an initial set of coding conventions before we switch the default. I expect that coding conventions will evolve quite a bit in the next few months, so we should do the switch after the first patch to codingconventions.html is approved and installed. A reasonable initial version of this should cover the core language features that allow implementing basic conversions (for instance, those that would allow re-implementing vec.h). I would like to avoid discussions to drag on indefinitely. But, given the magnitude of these changes, I suppose that it may take a few days to hash it out. Therefore, I propose that: - For the coding conventions, we have the explicit approval of at least 4 global reviewers. - For the build changes, approval from a build maintainer should be enough. Thanks. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-03 17:38 Switching to C++ by default in 4.8 Diego Novillo @ 2012-04-03 19:39 ` Paweł Sikora 2012-04-03 20:52 ` Ian Lance Taylor 2012-04-04 1:13 ` David Edelsohn 2012-04-04 7:07 ` Tristan Gingold 2 siblings, 1 reply; 182+ messages in thread From: Paweł Sikora @ 2012-04-03 19:39 UTC (permalink / raw) To: gcc; +Cc: Diego Novillo, Ian Lance Taylor, Lawrence Crowl On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote: > > Concurrently with this, Lawrence and Ian are working on the C++ coding > guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions. what about using http://astyle.sourceforge.net/astyle.html for code checkers? what about -Woverloaded-virtual [-Werror] by default? ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-03 19:39 ` Paweł Sikora @ 2012-04-03 20:52 ` Ian Lance Taylor 2012-04-03 21:34 ` Paweł Sikora 2012-04-04 5:19 ` Basile Starynkevitch 0 siblings, 2 replies; 182+ messages in thread From: Ian Lance Taylor @ 2012-04-03 20:52 UTC (permalink / raw) To: Paweł Sikora; +Cc: gcc, Diego Novillo, Lawrence Crowl Paweł Sikora <pluto@agmk.net> writes: > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote: >> >> Concurrently with this, Lawrence and Ian are working on the C++ coding >> guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions. > > what about using http://astyle.sourceforge.net/astyle.html for code checkers? I don't think we want to automatically reformat the entire GCC codebase. Or at least, if we do, we don't want to confuse that with the C++ transition. > what about -Woverloaded-virtual [-Werror] by default? Sounds good to me. -Werror will of course be on by default for stage 2 and 3 development builds. Want to add a cxx_strict_warn along the lines of c_strict_warn in gcc/configure.ac and gcc/Makefile.in? Ian ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-03 20:52 ` Ian Lance Taylor @ 2012-04-03 21:34 ` Paweł Sikora 2012-04-20 20:14 ` Joseph S. Myers 2012-04-04 5:19 ` Basile Starynkevitch 1 sibling, 1 reply; 182+ messages in thread From: Paweł Sikora @ 2012-04-03 21:34 UTC (permalink / raw) To: gcc; +Cc: Ian Lance Taylor, Diego Novillo, Lawrence Crowl On Tuesday 03 of April 2012 13:51:56 Ian Lance Taylor wrote: > Paweł Sikora <pluto@agmk.net> writes: > > > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote: > >> > >> Concurrently with this, Lawrence and Ian are working on the C++ coding > >> guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions. > > > > what about using http://astyle.sourceforge.net/astyle.html for code checkers? > > I don't think we want to automatically reformat the entire GCC codebase. > Or at least, if we do, we don't want to confuse that with the C++ > transition. i'm only suggesting that astyle (or another tool) can be used in svn pre-commit hook to verifying gnu formatting rules (incoming files can be extracted from svn transaction to /tmp and checked). manual formatting rules reviewing @gcc-patches is waste of time. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-03 21:34 ` Paweł Sikora @ 2012-04-20 20:14 ` Joseph S. Myers 0 siblings, 0 replies; 182+ messages in thread From: Joseph S. Myers @ 2012-04-20 20:14 UTC (permalink / raw) To: Paweł Sikora; +Cc: gcc, Ian Lance Taylor, Diego Novillo, Lawrence Crowl [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: TEXT/PLAIN; charset=utf-8, Size: 566 bytes --] On Tue, 3 Apr 2012, PaweÅ~B Sikora wrote: > i'm only suggesting that astyle (or another tool) can be used in svn pre-commit > hook to verifying gnu formatting rules (incoming files can be extracted from I think it's a bad idea to check anything in a pre-commit hook that isn't also covered by a normal build and testsuite run. Commit time is too late for detecting problems with patches; if you want automatic style checks then make them cause the build or testsuite run to fail if there are problems. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-03 20:52 ` Ian Lance Taylor 2012-04-03 21:34 ` Paweł Sikora @ 2012-04-04 5:19 ` Basile Starynkevitch 1 sibling, 0 replies; 182+ messages in thread From: Basile Starynkevitch @ 2012-04-04 5:19 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Paweł Sikora, gcc, Diego Novillo, Lawrence Crowl On Tue, 03 Apr 2012 13:51:56 -0700 Ian Lance Taylor <iant@google.com> wrote: > PaweÅ Sikora <pluto@agmk.net> writes: > > > On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote: > >> > >> Concurrently with this, Lawrence and Ian are working on the C++ coding > >> guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions. > > > > what about using http://astyle.sourceforge.net/astyle.html for code checkers? > > I don't think we want to automatically reformat the entire GCC codebase. > Or at least, if we do, we don't want to confuse that with the C++ > transition. But I believe we could install as a rule that every genuine C++ source file be indented with astyle -gnu -s2 and perhaps even provide an 'indent' make target for that purpose. I really think that systematic reindentation would help us a lot. What do you think? Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-03 17:38 Switching to C++ by default in 4.8 Diego Novillo 2012-04-03 19:39 ` Paweł Sikora @ 2012-04-04 1:13 ` David Edelsohn 2012-04-04 4:00 ` Ian Lance Taylor ` (2 more replies) 2012-04-04 7:07 ` Tristan Gingold 2 siblings, 3 replies; 182+ messages in thread From: David Edelsohn @ 2012-04-04 1:13 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote: > > We would like to start the process to make GCC 4.8 build in C++ mode by > default. > > The mechanics of the change are simple enough. I volunteer to test changing > the default on all primary targets (assuming I can get them from the GCC > build farm). I appreciate the motivation, but this may cause major problems on non-GNU/Linux platforms. Testing on all primary targets is not enough. Do you expect GCC to be able to bootstrap starting from a vendor C++ compiler or will this require G++? What is the earliest release of G++ that will allow GCC to bootstrap? Thanks, David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 1:13 ` David Edelsohn @ 2012-04-04 4:00 ` Ian Lance Taylor 2012-04-04 4:42 ` Miles Bader 2012-04-04 8:32 ` Gabriel Dos Reis 2012-04-04 11:22 ` Diego Novillo 2 siblings, 1 reply; 182+ messages in thread From: Ian Lance Taylor @ 2012-04-04 4:00 UTC (permalink / raw) To: David Edelsohn; +Cc: Diego Novillo, gcc David Edelsohn <dje.gcc@gmail.com> writes: > Do you expect GCC to be able to bootstrap starting from a vendor C++ > compiler or will this require G++? In principle it should be possible to start from a vendor C++ compiler. Of course we will have to test in order to see. > What is the earliest release of G++ that will allow GCC to bootstrap? Another thing that is worth testing. Right now I would anticipate that even fairly old releases of G++ can bootstrap GCC. However, we will need to decide what old release we want to ensure works. Ian ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 4:00 ` Ian Lance Taylor @ 2012-04-04 4:42 ` Miles Bader 0 siblings, 0 replies; 182+ messages in thread From: Miles Bader @ 2012-04-04 4:42 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: David Edelsohn, Diego Novillo, gcc Ian Lance Taylor <iant@google.com> writes: >> What is the earliest release of G++ that will allow GCC to bootstrap? > > Another thing that is worth testing. Right now I would anticipate that > even fairly old releases of G++ can bootstrap GCC. However, we will > need to decide what old release we want to ensure works. 4.2 at the latest might be a good idea, given its continued widespread use in "scared of the GPL3"[*] communities (*BSD, the pre-clang llvm frontend, the pathscale/path64 compiler frontend, etc)... [*] stronger language omitted for diplomatic reasons -miles -- Zeal, n. A certain nervous disorder afflicting the young and inexperienced. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 1:13 ` David Edelsohn 2012-04-04 4:00 ` Ian Lance Taylor @ 2012-04-04 8:32 ` Gabriel Dos Reis 2012-04-04 9:06 ` Richard Guenther 2012-04-04 11:22 ` Diego Novillo 2 siblings, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-04 8:32 UTC (permalink / raw) To: David Edelsohn; +Cc: Diego Novillo, gcc On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote: > On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote: >> >> We would like to start the process to make GCC 4.8 build in C++ mode by >> default. >> >> The mechanics of the change are simple enough. I volunteer to test changing >> the default on all primary targets (assuming I can get them from the GCC >> build farm). > > I appreciate the motivation, but this may cause major problems on > non-GNU/Linux platforms. Testing on all primary targets is not > enough. > > Do you expect GCC to be able to bootstrap starting from a vendor C++ > compiler or will this require G++? I would expect that we use C++03, and any C++ compiler. > What is the earliest release of G++ that will allow GCC to bootstrap? Any G++ from the last five years should be good. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 8:32 ` Gabriel Dos Reis @ 2012-04-04 9:06 ` Richard Guenther 2012-04-04 9:10 ` Gabriel Dos Reis ` (3 more replies) 0 siblings, 4 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-04 9:06 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote: >> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote: >>> >>> We would like to start the process to make GCC 4.8 build in C++ mode by >>> default. >>> >>> The mechanics of the change are simple enough. I volunteer to test changing >>> the default on all primary targets (assuming I can get them from the GCC >>> build farm). >> >> I appreciate the motivation, but this may cause major problems on >> non-GNU/Linux platforms. Testing on all primary targets is not >> enough. >> >> Do you expect GCC to be able to bootstrap starting from a vendor C++ >> compiler or will this require G++? > > I would expect that we use C++03, and any C++ compiler. Yes. Thus, for stage1 we should force -std=c++03 -pedantic if we build with GCC to avoid creep in of GNU features. Btw, I think we should only start forcing C++ when 1) there is a branch/patch out that shows benefit from using C++. I previously mentioned that I'd like to see 2) a patch that _properly_ wraps a C++ class for consumption by our garbage collector (thus, not a hack that works for a specific case but infrastructure that we think will work for _all_ cases, including libstdc++ container use). So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined by transitioning vec.h to a C++ template class, with proper GC support. (not sure that I can veto anything - heh) Thanks, Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 9:06 ` Richard Guenther @ 2012-04-04 9:10 ` Gabriel Dos Reis 2012-04-04 9:15 ` Gabriel Dos Reis ` (2 subsequent siblings) 3 siblings, 0 replies; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-04 9:10 UTC (permalink / raw) To: Richard Guenther; +Cc: David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > (not sure that I can veto anything - heh) I found out that is the only power a Release Manager has -- apart from fixing the bug himself or herself ;-p -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 9:06 ` Richard Guenther 2012-04-04 9:10 ` Gabriel Dos Reis @ 2012-04-04 9:15 ` Gabriel Dos Reis 2012-04-04 9:59 ` Richard Guenther 2012-04-04 11:20 ` Diego Novillo 2012-04-04 11:53 ` Bernd Schmidt 3 siblings, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-04 9:15 UTC (permalink / raw) To: Richard Guenther; +Cc: David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis > <gdr@integrable-solutions.net> wrote: >> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote: >>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote: >>>> >>>> We would like to start the process to make GCC 4.8 build in C++ mode by >>>> default. >>>> >>>> The mechanics of the change are simple enough. I volunteer to test changing >>>> the default on all primary targets (assuming I can get them from the GCC >>>> build farm). >>> >>> I appreciate the motivation, but this may cause major problems on >>> non-GNU/Linux platforms. Testing on all primary targets is not >>> enough. >>> >>> Do you expect GCC to be able to bootstrap starting from a vendor C++ >>> compiler or will this require G++? >> >> I would expect that we use C++03, and any C++ compiler. > > Yes. Thus, for stage1 we should force -std=c++03 -pedantic if we > build with GCC to > avoid creep in of GNU features. Fully agreed. > Btw, I think we should only start forcing C++ when 1) there is a > branch/patch out > that shows benefit from using C++. I previously mentioned that I'd like to see > 2) a patch that _properly_ wraps a C++ class for consumption by our garbage > collector (thus, not a hack that works for a specific case but infrastructure > that we think will work for _all_ cases, including libstdc++ container use). I was actually thinking starting with abstractions that do not interact directly with the memory manager, because I would like us to get our feet wet before doing the full plunge. Such a work would be confined to a part of the compiler (say the C++ front-end). Any particular reason you would like to start with the garbage collector which touches just about anything? -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 9:15 ` Gabriel Dos Reis @ 2012-04-04 9:59 ` Richard Guenther 2012-04-04 10:02 ` Richard Guenther 0 siblings, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-04 9:59 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 11:15 AM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther > <richard.guenther@gmail.com> wrote: >> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis >> <gdr@integrable-solutions.net> wrote: >>> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote: >>>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote: >>>>> >>>>> We would like to start the process to make GCC 4.8 build in C++ mode by >>>>> default. >>>>> >>>>> The mechanics of the change are simple enough. I volunteer to test changing >>>>> the default on all primary targets (assuming I can get them from the GCC >>>>> build farm). >>>> >>>> I appreciate the motivation, but this may cause major problems on >>>> non-GNU/Linux platforms. Testing on all primary targets is not >>>> enough. >>>> >>>> Do you expect GCC to be able to bootstrap starting from a vendor C++ >>>> compiler or will this require G++? >>> >>> I would expect that we use C++03, and any C++ compiler. >> >> Yes. Thus, for stage1 we should force -std=c++03 -pedantic if we >> build with GCC to >> avoid creep in of GNU features. > > Fully agreed. > >> Btw, I think we should only start forcing C++ when 1) there is a >> branch/patch out >> that shows benefit from using C++. I previously mentioned that I'd like to see >> 2) a patch that _properly_ wraps a C++ class for consumption by our garbage >> collector (thus, not a hack that works for a specific case but infrastructure >> that we think will work for _all_ cases, including libstdc++ container use). > > I was actually thinking starting with abstractions that do not interact directly > with the memory manager, because I would like us to get our feet wet > before doing the full plunge. Such a work would be confined to a part of > the compiler (say the C++ front-end). Any particular reason you would > like to start > with the garbage collector which touches just about anything? Because the garbage collector is the thing that will block reasonable use of C++ if we cannot get it working. And because of the fear that if we don't show how to do it _right_ first then people will start inventing a dozent different ways of making it work for a special case. Note that I don't think it will touch everything. I remember we discussed how to do it and basically settled on something like template <class T> struct gc_mark { static void mark (T *) {} } and specializations that actually do something meaningful. which we can provide specializations for all existing types walked by gengtype trivially. This would provide a way to support GCing objects whose types are not "supported" by gengtype - gengtype would simply emit gc_mark<T>::mark () calls which are trivially optimized away if there is nothing to mark. That said - somebody would need to prototype that, and VEC is a good candidate I think because it's used both with GC and non-GC memory. Richard. > -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 9:59 ` Richard Guenther @ 2012-04-04 10:02 ` Richard Guenther 0 siblings, 0 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-04 10:02 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 11:59 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Apr 4, 2012 at 11:15 AM, Gabriel Dos Reis > <gdr@integrable-solutions.net> wrote: >> On Wed, Apr 4, 2012 at 4:06 AM, Richard Guenther >> <richard.guenther@gmail.com> wrote: >>> On Wed, Apr 4, 2012 at 10:32 AM, Gabriel Dos Reis >>> <gdr@integrable-solutions.net> wrote: >>>> On Tue, Apr 3, 2012 at 8:13 PM, David Edelsohn <dje.gcc@gmail.com> wrote: >>>>> On Tue, Apr 3, 2012 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote: >>>>>> >>>>>> We would like to start the process to make GCC 4.8 build in C++ mode by >>>>>> default. >>>>>> >>>>>> The mechanics of the change are simple enough. I volunteer to test changing >>>>>> the default on all primary targets (assuming I can get them from the GCC >>>>>> build farm). >>>>> >>>>> I appreciate the motivation, but this may cause major problems on >>>>> non-GNU/Linux platforms. Testing on all primary targets is not >>>>> enough. >>>>> >>>>> Do you expect GCC to be able to bootstrap starting from a vendor C++ >>>>> compiler or will this require G++? >>>> >>>> I would expect that we use C++03, and any C++ compiler. >>> >>> Yes. Thus, for stage1 we should force -std=c++03 -pedantic if we >>> build with GCC to >>> avoid creep in of GNU features. >> >> Fully agreed. >> >>> Btw, I think we should only start forcing C++ when 1) there is a >>> branch/patch out >>> that shows benefit from using C++. I previously mentioned that I'd like to see >>> 2) a patch that _properly_ wraps a C++ class for consumption by our garbage >>> collector (thus, not a hack that works for a specific case but infrastructure >>> that we think will work for _all_ cases, including libstdc++ container use). >> >> I was actually thinking starting with abstractions that do not interact directly >> with the memory manager, because I would like us to get our feet wet >> before doing the full plunge. Such a work would be confined to a part of >> the compiler (say the C++ front-end). Any particular reason you would >> like to start >> with the garbage collector which touches just about anything? > > Because the garbage collector is the thing that will block reasonable use > of C++ if we cannot get it working. And because of the fear that if we > don't show how to do it _right_ first then people will start inventing a dozent > different ways of making it work for a special case. > > Note that I don't think it will touch everything. I remember we discussed how > to do it and basically settled on something like > > template <class T> > struct gc_mark { > static void mark (T *) {} > } > > and specializations that actually do something meaningful. > > which we can provide specializations for all existing types walked by > gengtype trivially. This would provide a way to support GCing objects > whose types are not "supported" by gengtype - gengtype would simply > emit gc_mark<T>::mark () calls which are trivially optimized away > if there is nothing to mark. > > That said - somebody would need to prototype that, and VEC is a good > candidate I think because it's used both with GC and non-GC memory. This will, of course, be also a challenge for various non-GCC host C++ compilers ;) (let's hope they get this part of templates right ... thus, let's avoid the need to do partial specialization at least). > Richard. > >> -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 9:06 ` Richard Guenther 2012-04-04 9:10 ` Gabriel Dos Reis 2012-04-04 9:15 ` Gabriel Dos Reis @ 2012-04-04 11:20 ` Diego Novillo 2012-04-04 11:38 ` Richard Guenther 2012-04-05 12:40 ` Pedro Lamarão 2012-04-04 11:53 ` Bernd Schmidt 3 siblings, 2 replies; 182+ messages in thread From: Diego Novillo @ 2012-04-04 11:20 UTC (permalink / raw) To: Richard Guenther; +Cc: Gabriel Dos Reis, David Edelsohn, gcc On 4/4/12 5:06 AM, Richard Guenther wrote: > Btw, I think we should only start forcing C++ when 1) there is a > branch/patch out > that shows benefit from using C++. I previously mentioned that I'd like to see > 2) a patch that _properly_ wraps a C++ class for consumption by our garbage > collector (thus, not a hack that works for a specific case but infrastructure > that we think will work for _all_ cases, including libstdc++ container use). My idea was to start with something like converting VEC() which would require dealing with GC. I did not intend to make the conversion and the switch as a single operation, however. Seemed like too much to change in a single patch. > So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined > by transitioning vec.h to a C++ template class, with proper GC support. > (not sure that I can veto anything - heh) Well, none of us can, really. Except maybe RMs in the context of release branches. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 11:20 ` Diego Novillo @ 2012-04-04 11:38 ` Richard Guenther 2012-04-04 14:12 ` Tom Tromey 2012-04-14 1:35 ` Chiheng Xu 2012-04-05 12:40 ` Pedro Lamarão 1 sibling, 2 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-04 11:38 UTC (permalink / raw) To: Diego Novillo; +Cc: Gabriel Dos Reis, David Edelsohn, gcc On Wed, Apr 4, 2012 at 1:20 PM, Diego Novillo <dnovillo@google.com> wrote: > On 4/4/12 5:06 AM, Richard Guenther wrote: > >> Btw, I think we should only start forcing C++ when 1) there is a >> branch/patch out >> that shows benefit from using C++. I previously mentioned that I'd like >> to see >> 2) a patch that _properly_ wraps a C++ class for consumption by our >> garbage >> collector (thus, not a hack that works for a specific case but >> infrastructure >> that we think will work for _all_ cases, including libstdc++ container >> use). > > > My idea was to start with something like converting VEC() which would > require dealing with GC. > > I did not intend to make the conversion and the switch as a single > operation, however. Seemed like too much to change in a single patch. > > >> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be >> combined >> by transitioning vec.h to a C++ template class, with proper GC support. >> (not sure that I can veto anything - heh) I think vec.h is the canonical example of something that we agree on that using C++ is an improvement and a case where we have to get GC support right. If you say the changes doing GC "right" and transforming vec.h are too big to be done together, then well. You only know if you did things right if you have both the "new" GC and a user (vec.h in C++). So yes, maybe too big for a patch but not too big for a branch (where you could merge the GC infrastructure changes separately from the vec.h change). But both need to be developed together. Oh, and did we address all the annoyances of debugging gcc when it's compiled by a C++ compiler? ... Richard. > Well, none of us can, really. Except maybe RMs in the context of release > branches. > > > Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 11:38 ` Richard Guenther @ 2012-04-04 14:12 ` Tom Tromey 2012-04-04 14:45 ` Richard Guenther 2012-04-14 1:35 ` Chiheng Xu 1 sibling, 1 reply; 182+ messages in thread From: Tom Tromey @ 2012-04-04 14:12 UTC (permalink / raw) To: Richard Guenther; +Cc: Diego Novillo, Gabriel Dos Reis, David Edelsohn, gcc >>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes: Richard> Oh, and did we address all the annoyances of debugging gcc when it's Richard> compiled by a C++ compiler? ... If you mean gdb problems, please file bugs. Tom ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 14:12 ` Tom Tromey @ 2012-04-04 14:45 ` Richard Guenther 2012-04-04 14:48 ` Richard Guenther 0 siblings, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-04 14:45 UTC (permalink / raw) To: Tom Tromey; +Cc: Diego Novillo, Gabriel Dos Reis, David Edelsohn, gcc On Wed, Apr 4, 2012 at 4:12 PM, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes: > > Richard> Oh, and did we address all the annoyances of debugging gcc when it's > Richard> compiled by a C++ compiler? ... > > If you mean gdb problems, please file bugs. I think I filed the most annoying one already, passing cut&pasted addresses to inferior calls and gdb doing funny overload resolution on the pointer types. Not sure what its status is. Richard. > Tom ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 14:45 ` Richard Guenther @ 2012-04-04 14:48 ` Richard Guenther 0 siblings, 0 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-04 14:48 UTC (permalink / raw) To: Tom Tromey; +Cc: Diego Novillo, Gabriel Dos Reis, David Edelsohn, gcc On Wed, Apr 4, 2012 at 4:45 PM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Apr 4, 2012 at 4:12 PM, Tom Tromey <tromey@redhat.com> wrote: >>>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes: >> >> Richard> Oh, and did we address all the annoyances of debugging gcc when it's >> Richard> compiled by a C++ compiler? ... >> >> If you mean gdb problems, please file bugs. > > I think I filed the most annoying one already, passing cut&pasted addresses > to inferior calls and gdb doing funny overload resolution on the pointer types. > Not sure what its status is. Seems unfixed: http://sourceware.org/bugzilla/show_bug.cgi?id=13356 > Richard. > >> Tom ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 11:38 ` Richard Guenther 2012-04-04 14:12 ` Tom Tromey @ 2012-04-14 1:35 ` Chiheng Xu 2012-04-14 9:09 ` Robert Dewar 1 sibling, 1 reply; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 1:35 UTC (permalink / raw) To: Richard Guenther; +Cc: Diego Novillo, Gabriel Dos Reis, David Edelsohn, gcc On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther <richard.guenther@gmail.com> wrote: > > Oh, and did we address all the annoyances of debugging gcc when it's > compiled by a C++ compiler? ... > Probably, if you can refrain from using some "advance" C++ features(namespace, template, etc.), you will not have such annoyances. -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 1:35 ` Chiheng Xu @ 2012-04-14 9:09 ` Robert Dewar 2012-04-14 10:03 ` Chiheng Xu 2012-04-14 10:39 ` Gabriel Dos Reis 0 siblings, 2 replies; 182+ messages in thread From: Robert Dewar @ 2012-04-14 9:09 UTC (permalink / raw) To: Chiheng Xu Cc: Richard Guenther, Diego Novillo, Gabriel Dos Reis, David Edelsohn, gcc On 4/13/2012 9:34 PM, Chiheng Xu wrote: > On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther > <richard.guenther@gmail.com> wrote: >> >> Oh, and did we address all the annoyances of debugging gcc when it's >> compiled by a C++ compiler? ... >> > > Probably, if you can refrain from using some "advance" C++ > features(namespace, template, etc.), you will not have such > annoyances. To me namespaces are fundamental in terms of the advantages that moving to C++ can give in a large project, I would never regard them as some "advanced" feature to be avoided. If namespaces cause trouble for the debugger, that's surprising and problematic! > ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 9:09 ` Robert Dewar @ 2012-04-14 10:03 ` Chiheng Xu 2012-04-14 11:13 ` Robert Dewar 2012-04-14 11:41 ` Jonathan Wakely 2012-04-14 10:39 ` Gabriel Dos Reis 1 sibling, 2 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 10:03 UTC (permalink / raw) To: Robert Dewar Cc: Richard Guenther, Diego Novillo, Gabriel Dos Reis, David Edelsohn, gcc On Sat, Apr 14, 2012 at 5:09 PM, Robert Dewar <dewar@adacore.com> wrote: > On 4/13/2012 9:34 PM, Chiheng Xu wrote: >> >> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther >> <richard.guenther@gmail.com> wrote: >>> >>> >>> Oh, and did we address all the annoyances of debugging gcc when it's >>> compiled by a C++ compiler? ... >>> >> >> Probably, if you can refrain from using some "advance" C++ >> features(namespace, template, etc.), you will not have such >> annoyances. > > > To me namespaces are fundamental in terms of the advantages that > moving to C++ can give in a large project, I would never regard > them as some "advanced" feature to be avoided. If namespaces > cause trouble for the debugger, that's surprising and problematic! >> >> > If debugger fully support namespace, that will be nice. I just say, in case debugger have trouble with namespace, you can avoid it. But personally, when I write C++ code, I never use namespace. I always prefix my class name(and corresponding source file names) with proper module name, and put the all source files of a module in its dedicated sub-directory . This make class name globally unique throughout the project, and facilitate further re-factoring(searching and replacing). When using namespace, people can and tend to use the same name in different namespaces, this seems like a advantage, but I see it as a disadvantage. If you want to change a name in one namespace to some other more accurate/proper name, you use some search tools to search all the references of the name, you will find that the name is probably also used in other namespaces, so you just can't use "replace all" command to replace all references with the new name, you must manually replace them one by one. Is this what you want ?. And, frankly speaking, I don't like "::". For example A::B, sometime it means name B in namespace A, sometime it means member B of class A. This depend whether A is class or namespace. But when you first read code, this information is unclear, you must guess, until you have read enough code to known what A is. -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 10:03 ` Chiheng Xu @ 2012-04-14 11:13 ` Robert Dewar 2012-04-14 11:41 ` Jonathan Wakely 1 sibling, 0 replies; 182+ messages in thread From: Robert Dewar @ 2012-04-14 11:13 UTC (permalink / raw) To: Chiheng Xu Cc: Richard Guenther, Diego Novillo, Gabriel Dos Reis, David Edelsohn, gcc On 4/14/2012 6:02 AM, Chiheng Xu wrote: > If debugger fully support namespace, that will be nice. I just say, > in case debugger have trouble with namespace, you can avoid it. > > But personally, when I write C++ code, I never use namespace. I > always prefix my class name(and corresponding source file names) with > proper module name, and put the all source files of a module in its > dedicated sub-directory . This make class name globally unique > throughout the project, and facilitate further re-factoring(searching > and replacing). I find that rather a horrible substitute for proper use of namespaces. I know it is common, partly because that's what you have to do in C, and partly because namespac3es were added late > > When using namespace, people can and tend to use the same name in > different namespaces, this seems like a advantage, but I see it as a > disadvantage. I think that is a seriously misguided position. There is a good reason for adding namespaces (Ada has always had this kind of capability in the form of packages, and the package concept in Ada is, to Ada programmers, one of its most powerful features). Since you never use namespaces, it is not surprising that you do not appreicate their importance. To me, the ability to make extensive use of namespaces is one of the strong arguments for switching to C++ > If you want to change a name in one namespace to some > other more accurate/proper name, you use some search tools to search > all the references of the name, you will find that the name is > probably also used in other namespaces, so you just can't use "replace > all" command to replace all references with the new name, you must > manually replace them one by one. Is this what you want ?. You use proper tools that do the replacement just of references to the entity whose name you want to change. It is often the case that people avoid use of features because of a lack of proper tools, but certainly there are tools that can do this kind of intelligent replacement (GPS from AdaCore is one such example, but we certainly wouldn't suggest it was unique in this respect!) ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 10:03 ` Chiheng Xu 2012-04-14 11:13 ` Robert Dewar @ 2012-04-14 11:41 ` Jonathan Wakely 1 sibling, 0 replies; 182+ messages in thread From: Jonathan Wakely @ 2012-04-14 11:41 UTC (permalink / raw) To: Chiheng Xu Cc: Robert Dewar, Richard Guenther, Diego Novillo, Gabriel Dos Reis, David Edelsohn, gcc On 14 April 2012 11:02, Chiheng Xu wrote: > > If debugger fully support namespace, that will be nice. I just say, > in case debugger have trouble with namespace, you can avoid it. So it's completely unfounded speculation then. > But personally, when I write C++ code, I never use namespace. I > always prefix my class name(and corresponding source file names) with > proper module name, and put the all source files of a module in its > dedicated sub-directory . This make class name globally unique > throughout the project, and facilitate further re-factoring(searching > and replacing). Find'n'replace is not refactoring. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 9:09 ` Robert Dewar 2012-04-14 10:03 ` Chiheng Xu @ 2012-04-14 10:39 ` Gabriel Dos Reis 2012-04-14 11:08 ` Robert Dewar 1 sibling, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-14 10:39 UTC (permalink / raw) To: Robert Dewar Cc: Chiheng Xu, Richard Guenther, Diego Novillo, David Edelsohn, gcc On Sat, Apr 14, 2012 at 4:09 AM, Robert Dewar <dewar@adacore.com> wrote: > On 4/13/2012 9:34 PM, Chiheng Xu wrote: >> >> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther >> <richard.guenther@gmail.com> wrote: >>> >>> >>> Oh, and did we address all the annoyances of debugging gcc when it's >>> compiled by a C++ compiler? ... >>> >> >> Probably, if you can refrain from using some "advance" C++ >> features(namespace, template, etc.), you will not have such >> annoyances. > > > To me namespaces are fundamental in terms of the advantages that > moving to C++ can give in a large project, I would never regard > them as some "advanced" feature to be avoided. If namespaces > cause trouble for the debugger, that's surprising and problematic! Indeed, the notion that 'namspace' is "advance" is troublesome. Similarly I would find any notion that simple uses and definitions of templates (functions, datatypes) "advanced" a bit specious. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 10:39 ` Gabriel Dos Reis @ 2012-04-14 11:08 ` Robert Dewar 2012-04-16 9:37 ` Chiheng Xu 0 siblings, 1 reply; 182+ messages in thread From: Robert Dewar @ 2012-04-14 11:08 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Chiheng Xu, Richard Guenther, Diego Novillo, David Edelsohn, gcc On 4/14/2012 6:39 AM, Gabriel Dos Reis wrote: > Indeed, the notion that 'namspace' is "advance" is troublesome. > Similarly I would find any notion that simple uses and definitions > of templates (functions, datatypes) "advanced" a bit specious. Indeed! In the case of templates there is a real issue, in that we all know that misuse of templates can get completely out of hand, but to suggest banning all templates is not a supportable notion. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 11:08 ` Robert Dewar @ 2012-04-16 9:37 ` Chiheng Xu 2012-04-16 9:38 ` Jonathan Wakely 2012-04-17 9:11 ` Robert Dewar 0 siblings, 2 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-16 9:37 UTC (permalink / raw) To: Robert Dewar Cc: Gabriel Dos Reis, Richard Guenther, Diego Novillo, David Edelsohn, gcc On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar <dewar@adacore.com> wrote: > hand, but to suggest banning all templates is not a supportable > notion. > Why ? -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-16 9:37 ` Chiheng Xu @ 2012-04-16 9:38 ` Jonathan Wakely 2012-04-17 9:11 ` Robert Dewar 1 sibling, 0 replies; 182+ messages in thread From: Jonathan Wakely @ 2012-04-16 9:38 UTC (permalink / raw) To: Chiheng Xu Cc: Robert Dewar, Gabriel Dos Reis, Richard Guenther, Diego Novillo, David Edelsohn, gcc On 16 April 2012 10:36, Chiheng Xu wrote: > On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar <dewar@adacore.com> wrote: >> hand, but to suggest banning all templates is not a supportable >> notion. >> > > Why ? Because they're useful. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-16 9:37 ` Chiheng Xu 2012-04-16 9:38 ` Jonathan Wakely @ 2012-04-17 9:11 ` Robert Dewar 1 sibling, 0 replies; 182+ messages in thread From: Robert Dewar @ 2012-04-17 9:11 UTC (permalink / raw) To: Chiheng Xu Cc: Gabriel Dos Reis, Richard Guenther, Diego Novillo, David Edelsohn, gcc On 4/16/2012 5:36 AM, Chiheng Xu wrote: > On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar<dewar@adacore.com> wrote: >> hand, but to suggest banning all templates is not a supportable >> notion. >> > > Why ? > > Because some simple uses of templates are very useful, and not problematic from any point of view. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 11:20 ` Diego Novillo 2012-04-04 11:38 ` Richard Guenther @ 2012-04-05 12:40 ` Pedro Lamarão 2012-04-05 13:05 ` Richard Guenther 1 sibling, 1 reply; 182+ messages in thread From: Pedro Lamarão @ 2012-04-05 12:40 UTC (permalink / raw) To: gcc On 04/04/2012 08:20 AM, Diego Novillo wrote: > On 4/4/12 5:06 AM, Richard Guenther wrote: > >> Btw, I think we should only start forcing C++ when 1) there is a >> branch/patch out >> that shows benefit from using C++. I previously mentioned that I'd >> like to see >> 2) a patch that _properly_ wraps a C++ class for consumption by our >> garbage >> collector (thus, not a hack that works for a specific case but >> infrastructure >> that we think will work for _all_ cases, including libstdc++ container >> use). > > My idea was to start with something like converting VEC() which would > require dealing with GC. Is anyone currently working or this? I'm not experienced in the code base, but this project seems fascinating. -- P. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 12:40 ` Pedro Lamarão @ 2012-04-05 13:05 ` Richard Guenther 2012-04-05 14:21 ` Diego Novillo 0 siblings, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-05 13:05 UTC (permalink / raw) To: Pedro Lamarão; +Cc: gcc On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão <pedro.lamarao@gmail.com> wrote: > On 04/04/2012 08:20 AM, Diego Novillo wrote: >> >> On 4/4/12 5:06 AM, Richard Guenther wrote: >> >>> Btw, I think we should only start forcing C++ when 1) there is a >>> branch/patch out >>> that shows benefit from using C++. I previously mentioned that I'd >>> like to see >>> 2) a patch that _properly_ wraps a C++ class for consumption by our >>> garbage >>> collector (thus, not a hack that works for a specific case but >>> infrastructure >>> that we think will work for _all_ cases, including libstdc++ container >>> use). >> >> >> My idea was to start with something like converting VEC() which would >> require dealing with GC. > > > Is anyone currently working or this? > > I'm not experienced in the code base, but this project seems fascinating. I'm not aware of anyone - so go ahead (if you happen to have a copyright assignment on file). Try to avoid to have to adjust vec.h users at start, thus keep the macro wrappings (to the extent this is possible, of course). The GC part is most interesting, the vec.h part should be quite obvious. Richard. > -- > P. > > ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 13:05 ` Richard Guenther @ 2012-04-05 14:21 ` Diego Novillo 2012-04-05 14:24 ` Richard Guenther 2012-04-10 22:04 ` Pedro Lamarão 0 siblings, 2 replies; 182+ messages in thread From: Diego Novillo @ 2012-04-05 14:21 UTC (permalink / raw) To: Richard Guenther; +Cc: Pedro Lamarão, gcc On Thu, Apr 5, 2012 at 09:04, Richard Guenther <richard.guenther@gmail.com> wrote: > On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão <pedro.lamarao@gmail.com> wrote: >> >> Is anyone currently working or this? >> >> I'm not experienced in the code base, but this project seems fascinating. > > I'm not aware of anyone - so go ahead (if you happen to have a copyright > assignment on file). I will be, after the switch to C++ is done. Pedro, if you do have a copyright assignment, feel free to start working on this. I suggest creating a branch for this (I can handle that today). If you need forms for the copyright assignment, let me know and I'll forward them to you. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 14:21 ` Diego Novillo @ 2012-04-05 14:24 ` Richard Guenther 2012-04-05 14:36 ` Diego Novillo 2012-04-10 22:04 ` Pedro Lamarão 1 sibling, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-05 14:24 UTC (permalink / raw) To: Diego Novillo; +Cc: Pedro Lamarão, gcc On Thu, Apr 5, 2012 at 4:21 PM, Diego Novillo <dnovillo@google.com> wrote: > On Thu, Apr 5, 2012 at 09:04, Richard Guenther > <richard.guenther@gmail.com> wrote: >> On Thu, Apr 5, 2012 at 2:41 PM, Pedro Lamarão <pedro.lamarao@gmail.com> wrote: >>> >>> Is anyone currently working or this? >>> >>> I'm not experienced in the code base, but this project seems fascinating. >> >> I'm not aware of anyone - so go ahead (if you happen to have a copyright >> assignment on file). > > > I will be, after the switch to C++ is done. Which means never, because I think it's a prerequesite for switching? ;) Richard. > Pedro, if you do have a > copyright assignment, feel free to start working on this. I suggest > creating a branch for this (I can handle that today). If you need > forms for the copyright assignment, let me know and I'll forward them > to you. > > > Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 14:24 ` Richard Guenther @ 2012-04-05 14:36 ` Diego Novillo 2012-04-05 20:17 ` David Edelsohn 0 siblings, 1 reply; 182+ messages in thread From: Diego Novillo @ 2012-04-05 14:36 UTC (permalink / raw) To: Richard Guenther; +Cc: Pedro Lamarão, gcc On Thu, Apr 5, 2012 at 10:24, Richard Guenther <richard.guenther@gmail.com> wrote: > Which means never, because I think it's a prerequesite for switching? No. I was not clear. By "done", I meant that GCC builds with C++ in all the platforms we can test. I'm sending a testing plan later today with the list of targets I think should be tested. I am expecting to do some adjusting patches to get all the targets working. Whether the vec.h conversion is committed simultaneously with the C++ switch is a minor issue. The cleanup patches for C++ will certainly need to be committed first. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 14:36 ` Diego Novillo @ 2012-04-05 20:17 ` David Edelsohn 2012-04-05 20:36 ` Gabriel Dos Reis 0 siblings, 1 reply; 182+ messages in thread From: David Edelsohn @ 2012-04-05 20:17 UTC (permalink / raw) To: Diego Novillo; +Cc: Richard Guenther, Pedro Lamarão, gcc On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo <dnovillo@google.com> wrote: > On Thu, Apr 5, 2012 at 10:24, Richard Guenther > <richard.guenther@gmail.com> wrote: > >> Which means never, because I think it's a prerequesite for switching? > > No. I was not clear. By "done", I meant that GCC builds with C++ in > all the platforms we can test. > > I'm sending a testing plan later today with the list of targets I > think should be tested. I am expecting to do some adjusting patches > to get all the targets working. I tried bootstrapping on AIX using C++. I am able to bootstrap using G++, but not with IBM xlC. xlC is able to compile the GCC source code (with a lot of warning messages), but the build fails when the build passes GCC-specific no exception flags to xlC. NOEXCEPTION_FLAGS = -fno-exceptions -fno-rtti xlc -c -fno-exceptions -fno-rtti conftest.c does succeed, but xlc -fno-exceptions -fno-rtti conftest.c fails. I don't think -fno-rtti -fno-exceptions does what GCC expects. Also, I noticed that although GCC is configured with --enable-build-with-cxx , the configure tests use $CC, which might not be accurate. - David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 20:17 ` David Edelsohn @ 2012-04-05 20:36 ` Gabriel Dos Reis 2012-04-06 0:11 ` David Edelsohn 0 siblings, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-05 20:36 UTC (permalink / raw) To: David Edelsohn; +Cc: Diego Novillo, Richard Guenther, Pedro Lamarão, gcc On Thu, Apr 5, 2012 at 3:16 PM, David Edelsohn <dje.gcc@gmail.com> wrote: > On Thu, Apr 5, 2012 at 10:36 AM, Diego Novillo <dnovillo@google.com> wrote: >> On Thu, Apr 5, 2012 at 10:24, Richard Guenther >> <richard.guenther@gmail.com> wrote: >> >>> Which means never, because I think it's a prerequesite for switching? >> >> No. I was not clear. By "done", I meant that GCC builds with C++ in >> all the platforms we can test. >> >> I'm sending a testing plan later today with the list of targets I >> think should be tested. I am expecting to do some adjusting patches >> to get all the targets working. > > I tried bootstrapping on AIX using C++. > > I am able to bootstrap using G++, but not with IBM xlC. xlC is able > to compile the GCC source code (with a lot of warning messages), but > the build fails when the build passes GCC-specific no exception flags > to xlC. > > NOEXCEPTION_FLAGS = -fno-exceptions -fno-rtti > > xlc -c -fno-exceptions -fno-rtti conftest.c > > does succeed, but > > xlc -fno-exceptions -fno-rtti conftest.c > > fails. I don't think -fno-rtti -fno-exceptions does what GCC expects. Thanks for these data. I think -fno-rtti and -fno-exceptions don't make much sense at the linker level so we should leave them out, and use them only when "compiling", e.g. with "-c". > > Also, I noticed that although GCC is configured with > --enable-build-with-cxx , the configure tests use $CC, which might not > be accurate. that is correct. I suspect a patch for the switch will switch to $CXX. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 20:36 ` Gabriel Dos Reis @ 2012-04-06 0:11 ` David Edelsohn 2012-04-09 10:37 ` Richard Guenther 0 siblings, 1 reply; 182+ messages in thread From: David Edelsohn @ 2012-04-06 0:11 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Diego Novillo, Richard Guenther, Pedro Lamarão, gcc On Thu, Apr 5, 2012 at 4:35 PM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: >> xlc -fno-exceptions -fno-rtti conftest.c >> >> fails. I don't think -fno-rtti -fno-exceptions does what GCC expects. > > Thanks for these data. I think -fno-rtti and -fno-exceptions don't make > much sense at the linker level so we should leave them out, and use > them only when "compiling", e.g. with "-c". It is used when compiling, e.g. gcov.c, but when compiling and linking directly from source without an intermediate object file. - David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-06 0:11 ` David Edelsohn @ 2012-04-09 10:37 ` Richard Guenther 2012-04-09 15:07 ` David Edelsohn 0 siblings, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-09 10:37 UTC (permalink / raw) To: David Edelsohn; +Cc: Gabriel Dos Reis, Diego Novillo, Pedro Lamarão, gcc On Fri, Apr 6, 2012 at 2:11 AM, David Edelsohn <dje.gcc@gmail.com> wrote: > On Thu, Apr 5, 2012 at 4:35 PM, Gabriel Dos Reis > <gdr@integrable-solutions.net> wrote: > >>> xlc -fno-exceptions -fno-rtti conftest.c >>> >>> fails. I don't think -fno-rtti -fno-exceptions does what GCC expects. >> >> Thanks for these data. I think -fno-rtti and -fno-exceptions don't make >> much sense at the linker level so we should leave them out, and use >> them only when "compiling", e.g. with "-c". > > It is used when compiling, e.g. gcov.c, but when compiling and linking > directly from source without an intermediate object file. These flags should be only used for stage2+ or when compiling with GCC. Did you try to bootstrap with xlc or did you use --disable-bootstrap? gcov.c is supposed to be compiled with the built GCC C++ compiler. Richard. > - David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 10:37 ` Richard Guenther @ 2012-04-09 15:07 ` David Edelsohn 0 siblings, 0 replies; 182+ messages in thread From: David Edelsohn @ 2012-04-09 15:07 UTC (permalink / raw) To: Richard Guenther; +Cc: Gabriel Dos Reis, Diego Novillo, Pedro Lamarão, gcc On Mon, Apr 9, 2012 at 6:37 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > These flags should be only used for stage2+ or when compiling with GCC. > Did you try to bootstrap with xlc or did you use --disable-bootstrap? gcov.c > is supposed to be compiled with the built GCC C++ compiler. I was attempting to bootstrap with xlc and xlC -- the IBM C and C++ native compilers. - David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 14:21 ` Diego Novillo 2012-04-05 14:24 ` Richard Guenther @ 2012-04-10 22:04 ` Pedro Lamarão 2012-04-10 22:56 ` Diego Novillo 1 sibling, 1 reply; 182+ messages in thread From: Pedro Lamarão @ 2012-04-10 22:04 UTC (permalink / raw) To: Diego Novillo; +Cc: Richard Guenther, gcc 2012/4/5 Diego Novillo <dnovillo@google.com> > I will be, after the switch to C++ is done. Pedro, if you do have a > copyright assignment, feel free to start working on this. I suggest > creating a branch for this (I can handle that today). If you need > forms for the copyright assignment, let me know and I'll forward them > to you. (Second attempt, to avoid text/html in Gmail.) I think I have an appropriate copyright assignment for contributing to GCC -- recently, an old patch of mine was reused an applied. Perhaps I misunderstood some of the conditions and would have to submit more documentation this time. I'm not sure. I think I have a viable approach to refactor VEC into a template class while keeping all files intact. The only implication is changing CC_FOR_BUILD to use COMPILER etc. Perhaps someone wiser might want to do something better to ensure genflags etc. compile with C++. Whenever the branch is ready, or people want to review, or both, I can submit patches. -- Pedro Lamarão ∷ http://www.pedro.lamarao.nom.br/ "Sanity consists in the faculty of adjusting ideas in proper proportion." - Aleister Crowley ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 22:04 ` Pedro Lamarão @ 2012-04-10 22:56 ` Diego Novillo 0 siblings, 0 replies; 182+ messages in thread From: Diego Novillo @ 2012-04-10 22:56 UTC (permalink / raw) To: Pedro Lamarão; +Cc: Richard Guenther, gcc On 4/10/12 6:04 PM, Pedro Lamarão wrote: > 2012/4/5 Diego Novillo<dnovillo@google.com> > >> I will be, after the switch to C++ is done. Pedro, if you do have a >> copyright assignment, feel free to start working on this. I suggest >> creating a branch for this (I can handle that today). If you need >> forms for the copyright assignment, let me know and I'll forward them >> to you. > > (Second attempt, to avoid text/html in Gmail.) > > I think I have an appropriate copyright assignment for contributing to > GCC -- recently, an old patch of mine was reused an applied. Perhaps I > misunderstood some of the conditions and would have to submit more > documentation this time. I'm not sure. Yes, if you've already signed paperwork for GCC, then we do not need anything else. > I think I have a viable approach to refactor VEC into a template class > while keeping all files intact. The only implication is changing > CC_FOR_BUILD to use COMPILER etc. Perhaps someone wiser might want to > do something better to ensure genflags etc. compile with C++. Whenever > the branch is ready, or people want to review, or both, I can submit > patches. Great, thanks. Let me setup a branch. I'll contact you later with instructions. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 9:06 ` Richard Guenther ` (2 preceding siblings ...) 2012-04-04 11:20 ` Diego Novillo @ 2012-04-04 11:53 ` Bernd Schmidt 2012-04-04 12:04 ` Richard Guenther 3 siblings, 1 reply; 182+ messages in thread From: Bernd Schmidt @ 2012-04-04 11:53 UTC (permalink / raw) To: Richard Guenther; +Cc: Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 04/04/2012 11:06 AM, Richard Guenther wrote: > So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined > by transitioning vec.h to a C++ template class, with proper GC support. > (not sure that I can veto anything - heh) I don't think I can veto anything, but I'll go on the record again saying that I don't think this entire plan is a good idea. Write a new project in C++? Absolutely. Convert a large existing one to a different language? A huge waste of time that will distract us for years from actual user-visible changes. I also find debugging C++ in gdb somewhat more annoying than debugging plain C, and at the moment I always go back to a stage1 compiler. Bernd ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 11:53 ` Bernd Schmidt @ 2012-04-04 12:04 ` Richard Guenther 2012-04-04 14:59 ` Diego Novillo ` (3 more replies) 0 siblings, 4 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-04 12:04 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 04/04/2012 11:06 AM, Richard Guenther wrote: >> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined >> by transitioning vec.h to a C++ template class, with proper GC support. >> (not sure that I can veto anything - heh) > > I don't think I can veto anything, but I'll go on the record again > saying that I don't think this entire plan is a good idea. Write a new > project in C++? Absolutely. Convert a large existing one to a different > language? A huge waste of time that will distract us for years from > actual user-visible changes. I agree for the idea of converting all of GCC to C++ (whatever that means). I disagree for the part making the internal infrastructure easier to use, understand and maintain. Which means targeting mostly isolated sub-systems, like vec.h (and other various containers), double-int.[ch] (and other various way of representing and working with constants). Making tree or gimple a C++ class with inheritance and whatever is indeed a huge waste of time and existing developer ressources (that, if only because they have to adapt and maintain two completely different code-bases over some time). I expect the GCC core to maintain written in C, compiled by C++. > I also find debugging C++ in gdb somewhat more annoying than debugging > plain C, and at the moment I always go back to a stage1 compiler. Indeed - I'd be worried if my debugging efficiency decreases by more than 5%. Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 12:04 ` Richard Guenther @ 2012-04-04 14:59 ` Diego Novillo 2012-04-04 17:54 ` Lawrence Crowl ` (2 subsequent siblings) 3 siblings, 0 replies; 182+ messages in thread From: Diego Novillo @ 2012-04-04 14:59 UTC (permalink / raw) To: Richard Guenther; +Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, gcc On 4/4/12 8:04 AM, Richard Guenther wrote: > I agree for the idea of converting all of GCC to C++ (whatever that means). Right. The conversion that does happen, can be gradual. One other big advantage I see in this effort, is the transition to commonly used programming idioms and patterns. This will lower barriers of entry to new developers, which is crucial to the long term survival of the project. I've heard many new developers (experienced compiler developers even) express frustration at the obtuse and obscure patterns they find in GCC. > I disagree for the part making the internal infrastructure easier to use, > understand and maintain. Which means targeting mostly isolated sub-systems, > like vec.h (and other various containers), double-int.[ch] (and other various > way of representing and working with constants). Making tree or gimple a > C++ class with inheritance and whatever is indeed a huge waste of time > and existing developer ressources (that, if only because they have to adapt > and maintain two completely different code-bases over some time). > > I expect the GCC core to maintain written in C, compiled by C++. I'm not sure about that long term, but I agree that this will likely be true for several releases. We want to be careful, of course. Particularly with the core sub-systems. >> I also find debugging C++ in gdb somewhat more annoying than debugging >> plain C, and at the moment I always go back to a stage1 compiler. > > Indeed - I'd be worried if my debugging efficiency decreases by more than 5%. We should take this opportunity to help improve gdb by filing bugs. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 12:04 ` Richard Guenther 2012-04-04 14:59 ` Diego Novillo @ 2012-04-04 17:54 ` Lawrence Crowl 2012-04-05 9:18 ` Richard Guenther 2012-04-09 23:34 ` Xinliang David Li 2012-04-14 2:41 ` Chiheng Xu 3 siblings, 1 reply; 182+ messages in thread From: Lawrence Crowl @ 2012-04-04 17:54 UTC (permalink / raw) To: Richard Guenther Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/4/12, Richard Guenther <richard.guenther@gmail.com> wrote: > On Apr 4, 2012 Bernd Schmidt <bernds@codesourcery.com> wrote: > > On 04/04/2012 11:06 AM, Richard Guenther wrote: > > > So - I'll veto the switch unless I see 1) and 2). 1) and 2) > > > can be combined by transitioning vec.h to a C++ template class, > > > with proper GC support. (not sure that I can veto anything > > > - heh) > > > > I don't think I can veto anything, but I'll go on the record > > again saying that I don't think this entire plan is a good > > idea. Write a new project in C++? Absolutely. Convert a large > > existing one to a different language? A huge waste of time that > > will distract us for years from actual user-visible changes. > > I agree for the idea of converting all of GCC to C++ (whatever > that means). I disagree for the part making the internal > infrastructure easier to use, understand and maintain. Which > means targeting mostly isolated sub-systems, like vec.h (and > other various containers), double-int.[ch] (and other various > way of representing and working with constants). Making tree > or gimple a C++ class with inheritance and whatever is indeed > a huge waste of time and existing developer ressources (that, > if only because they have to adapt and maintain two completely > different code-bases over some time). Trees are presently a significant problem in that many static errors become dynamic errors, which entails more debugging. > I expect the GCC core to maintain written in C, compiled by C++. Converting VECs to C++ vectors vector would provide significant code clarity benefits. The files in which that is done would necessarily be C++ only. > > I also find debugging C++ in gdb somewhat more annoying than > > debugging plain C, and at the moment I always go back to a > > stage1 compiler. > > Indeed - I'd be worried if my debugging efficiency decreases by > more than 5%. If the number of debugging sessions was reduced by the same amount, the result would be a net wash. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 17:54 ` Lawrence Crowl @ 2012-04-05 9:18 ` Richard Guenther 2012-04-05 20:07 ` Lawrence Crowl 0 siblings, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-05 9:18 UTC (permalink / raw) To: Lawrence Crowl Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 7:53 PM, Lawrence Crowl <crowl@google.com> wrote: > On 4/4/12, Richard Guenther <richard.guenther@gmail.com> wrote: >> On Apr 4, 2012 Bernd Schmidt <bernds@codesourcery.com> wrote: >> > On 04/04/2012 11:06 AM, Richard Guenther wrote: >> > > So - I'll veto the switch unless I see 1) and 2). 1) and 2) >> > > can be combined by transitioning vec.h to a C++ template class, >> > > with proper GC support. (not sure that I can veto anything >> > > - heh) >> > >> > I don't think I can veto anything, but I'll go on the record >> > again saying that I don't think this entire plan is a good >> > idea. Write a new project in C++? Absolutely. Convert a large >> > existing one to a different language? A huge waste of time that >> > will distract us for years from actual user-visible changes. >> >> I agree for the idea of converting all of GCC to C++ (whatever >> that means). I disagree for the part making the internal >> infrastructure easier to use, understand and maintain. Which >> means targeting mostly isolated sub-systems, like vec.h (and >> other various containers), double-int.[ch] (and other various >> way of representing and working with constants). Making tree >> or gimple a C++ class with inheritance and whatever is indeed >> a huge waste of time and existing developer ressources (that, >> if only because they have to adapt and maintain two completely >> different code-bases over some time). > > Trees are presently a significant problem in that many static errors > become dynamic errors, which entails more debugging. How do you expect tree errors to become static? By using derived types everywhere? Note that this would only be possible in a _very_ limited sub-set of places. >> I expect the GCC core to maintain written in C, compiled by C++. > > Converting VECs to C++ vectors vector would provide significant code > clarity benefits. The files in which that is done would necessarily > be C++ only. I already had VECs as the very first and best example why C++ might be good. >> > I also find debugging C++ in gdb somewhat more annoying than >> > debugging plain C, and at the moment I always go back to a >> > stage1 compiler. >> >> Indeed - I'd be worried if my debugging efficiency decreases by >> more than 5%. > > If the number of debugging sessions was reduced by the same amount, > the result would be a net wash. I have no expectation that the number of debug sessions will be reduced. Richard. > -- > Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 9:18 ` Richard Guenther @ 2012-04-05 20:07 ` Lawrence Crowl 2012-04-09 10:40 ` Richard Guenther 0 siblings, 1 reply; 182+ messages in thread From: Lawrence Crowl @ 2012-04-05 20:07 UTC (permalink / raw) To: Richard Guenther Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/5/12, Richard Guenther <richard.guenther@gmail.com> wrote: > On Apr 4, 2012 Lawrence Crowl <crowl@google.com> wrote: > > On 4/4/12, Richard Guenther <richard.guenther@gmail.com> wrote: > > > Making tree or gimple a C++ class with inheritance and > > > whatever is indeed a huge waste of time and existing developer > > > ressources (that, if only because they have to adapt and > > > maintain two completely different code-bases over some time). > > > > Trees are presently a significant problem in that many static > > errors become dynamic errors, which entails more debugging. > > How do you expect tree errors to become static? By using derived > types everywhere? Note that this would only be possible in a > _very_ limited sub-set of places. Yes, a class hierarchy that directly represents the type hierarchy already implicit in trees. With that structure in place, functions that require a certain kind of tree as a parameter can say so directly in the parameter list. Functions that return a certain kind of tree can say so in the return type. Calling a function that is inappropriate to the type will result in a static error. Certainly there are cases where the type must be made more specific, and getting the wrong type here would necessarily be a dynamic check. However, the number of dynamic checks can be substantially reduced. To provide a specific example, suppose I have a common_decl *p and need to do extra work if it is a var_decl. do_general_work (p); if (var_decl *q = p->to_var ()) { do_var_work_1 (q); do_var_work_2 (q); do_var_work_3 (q); do_var_work_4 (q); } The only dynamic work is in the pointer conversion. All other function calls can be statically typed. > > > I expect the GCC core to maintain written in C, compiled > > > by C++. > > > > Converting VECs to C++ vectors vector would provide significant > > code clarity benefits. The files in which that is done would > > necessarily be C++ only. > > I already had VECs as the very first and best example why C++ > might be good. But my point was that if we're using a C++ vector, the files are not written in C any more. > > > > I also find debugging C++ in gdb somewhat more annoying > > > > than debugging plain C, and at the moment I always go back > > > > to a stage1 compiler. > > > > > > Indeed - I'd be worried if my debugging efficiency decreases > > > by more than 5%. > > > > If the number of debugging sessions was reduced by the same > > amount, the result would be a net wash. > > I have no expectation that the number of debug sessions will > be reduced. On the other hand, I do. There are many instances were I've debugged a problem to realize that it could have been a static type error. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-05 20:07 ` Lawrence Crowl @ 2012-04-09 10:40 ` Richard Guenther 2012-04-09 17:56 ` Lawrence Crowl 2012-04-14 3:04 ` Chiheng Xu 0 siblings, 2 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-09 10:40 UTC (permalink / raw) To: Lawrence Crowl Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl <crowl@google.com> wrote: > On 4/5/12, Richard Guenther <richard.guenther@gmail.com> wrote: >> On Apr 4, 2012 Lawrence Crowl <crowl@google.com> wrote: >> > On 4/4/12, Richard Guenther <richard.guenther@gmail.com> wrote: >> > > Making tree or gimple a C++ class with inheritance and >> > > whatever is indeed a huge waste of time and existing developer >> > > ressources (that, if only because they have to adapt and >> > > maintain two completely different code-bases over some time). >> > >> > Trees are presently a significant problem in that many static >> > errors become dynamic errors, which entails more debugging. >> >> How do you expect tree errors to become static? By using derived >> types everywhere? Note that this would only be possible in a >> _very_ limited sub-set of places. > > Yes, a class hierarchy that directly represents the type hierarchy > already implicit in trees. With that structure in place, functions > that require a certain kind of tree as a parameter can say so > directly in the parameter list. Functions that return a certain > kind of tree can say so in the return type. Calling a function > that is inappropriate to the type will result in a static error. > > Certainly there are cases where the type must be made more specific, > and getting the wrong type here would necessarily be a dynamic check. > However, the number of dynamic checks can be substantially reduced. > To provide a specific example, suppose I have a common_decl *p and > need to do extra work if it is a var_decl. > > do_general_work (p); > if (var_decl *q = p->to_var ()) > { > do_var_work_1 (q); > do_var_work_2 (q); > do_var_work_3 (q); > do_var_work_4 (q); > } > > The only dynamic work is in the pointer conversion. All other > function calls can be statically typed. Ok. But the above represents a completely different programming style than what we use currently. We do if (is_var_decl (p)) { do_var_work_1 (p); ... } so what I was refering to was static errors we get when we are able to promote function argument / return types to more specific sub-classes. >> > > I expect the GCC core to maintain written in C, compiled >> > > by C++. >> > >> > Converting VECs to C++ vectors vector would provide significant >> > code clarity benefits. The files in which that is done would >> > necessarily be C++ only. >> >> I already had VECs as the very first and best example why C++ >> might be good. > > But my point was that if we're using a C++ vector, the files are > not written in C any more. Of course - the whole point was to switch to C++ and start using C++ features. The point I wanted to raise is that the switch to C++ should happen with a change that is useful and that includes getting GC "right". Converting vec.h is such a change. Richard. >> > > > I also find debugging C++ in gdb somewhat more annoying >> > > > than debugging plain C, and at the moment I always go back >> > > > to a stage1 compiler. >> > > >> > > Indeed - I'd be worried if my debugging efficiency decreases >> > > by more than 5%. >> > >> > If the number of debugging sessions was reduced by the same >> > amount, the result would be a net wash. >> >> I have no expectation that the number of debug sessions will >> be reduced. > > On the other hand, I do. There are many instances were I've debugged > a problem to realize that it could have been a static type error. > > -- > Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 10:40 ` Richard Guenther @ 2012-04-09 17:56 ` Lawrence Crowl 2012-04-09 18:22 ` Jakub Jelinek 2012-04-14 3:04 ` Chiheng Xu 1 sibling, 1 reply; 182+ messages in thread From: Lawrence Crowl @ 2012-04-09 17:56 UTC (permalink / raw) To: Richard Guenther Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/9/12, Richard Guenther <richard.guenther@gmail.com> wrote: > On Thu, Apr 5, 2012 at 10:06 PM, Lawrence Crowl <crowl@google.com> wrote: >> On 4/5/12, Richard Guenther <richard.guenther@gmail.com> wrote: >>> How do you expect tree errors to become static? By using derived >>> types everywhere? Note that this would only be possible in a >>> _very_ limited sub-set of places. >> >> Yes, a class hierarchy that directly represents the type hierarchy >> already implicit in trees. With that structure in place, functions >> that require a certain kind of tree as a parameter can say so >> directly in the parameter list. Functions that return a certain >> kind of tree can say so in the return type. Calling a function >> that is inappropriate to the type will result in a static error. >> >> Certainly there are cases where the type must be made more specific, >> and getting the wrong type here would necessarily be a dynamic check. >> However, the number of dynamic checks can be substantially reduced. >> To provide a specific example, suppose I have a common_decl *p and >> need to do extra work if it is a var_decl. >> >> do_general_work (p); >> if (var_decl *q = p->to_var ()) >> { >> do_var_work_1 (q); >> do_var_work_2 (q); >> do_var_work_3 (q); >> do_var_work_4 (q); >> } >> >> The only dynamic work is in the pointer conversion. All other >> function calls can be statically typed. > > Ok. But the above represents a completely different programming > style than what we use currently. We do > > if (is_var_decl (p)) > { > do_var_work_1 (p); > ... > } > > so what I was refering to was static errors we get when we are > able to promote function argument / return types to more specific > sub-classes. Certainly fully exploiting a class hierarchy will require a migration of the source base. That can happen incrementally over time. In the meantime, there are other tasks that will show more immediate progress. >>> > > I expect the GCC core to maintain written in C, compiled >>> > > by C++. >>> > >>> > Converting VECs to C++ vectors vector would provide significant >>> > code clarity benefits. The files in which that is done would >>> > necessarily be C++ only. >>> >>> I already had VECs as the very first and best example why C++ >>> might be good. >> >> But my point was that if we're using a C++ vector, the files are >> not written in C any more. > > Of course - the whole point was to switch to C++ and start using > C++ features. The point I wanted to raise is that the switch to > C++ should happen with a change that is useful and that includes > getting GC "right". Converting vec.h is such a change. A build conversion to C++ is a precondition to any source change using C++, though the two could be bundled into one patch. In any event, I agree that the conversion needs to provide value. Vectors and hash tables are a good early target. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 17:56 ` Lawrence Crowl @ 2012-04-09 18:22 ` Jakub Jelinek 2012-04-09 18:52 ` Lawrence Crowl 2012-04-14 3:07 ` Chiheng Xu 0 siblings, 2 replies; 182+ messages in thread From: Jakub Jelinek @ 2012-04-09 18:22 UTC (permalink / raw) To: Lawrence Crowl Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: > A build conversion to C++ is a precondition to any source change > using C++, though the two could be bundled into one patch. In any > event, I agree that the conversion needs to provide value. Vectors > and hash tables are a good early target. Hash tables? Ugh, what is wrong with the hash tables we have right now in GCC? Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 18:22 ` Jakub Jelinek @ 2012-04-09 18:52 ` Lawrence Crowl 2012-04-09 18:54 ` Jakub Jelinek 2012-04-10 11:09 ` Richard Guenther 2012-04-14 3:07 ` Chiheng Xu 1 sibling, 2 replies; 182+ messages in thread From: Lawrence Crowl @ 2012-04-09 18:52 UTC (permalink / raw) To: Jakub Jelinek Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: > > A build conversion to C++ is a precondition to any source change > > using C++, though the two could be bundled into one patch. In any > > event, I agree that the conversion needs to provide value. Vectors > > and hash tables are a good early target. > > Hash tables? Ugh, what is wrong with the hash tables we have > right now in GCC? Lots of boiler plate involving casting to void*. Some of that boiler plate makes the optimizer less effective. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 18:52 ` Lawrence Crowl @ 2012-04-09 18:54 ` Jakub Jelinek 2012-04-09 21:15 ` Lawrence Crowl 2012-04-10 11:09 ` Richard Guenther 1 sibling, 1 reply; 182+ messages in thread From: Jakub Jelinek @ 2012-04-09 18:54 UTC (permalink / raw) To: Lawrence Crowl Cc: Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Mon, Apr 09, 2012 at 11:51:56AM -0700, Lawrence Crowl wrote: > On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote: > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: > > > A build conversion to C++ is a precondition to any source change > > > using C++, though the two could be bundled into one patch. In any > > > event, I agree that the conversion needs to provide value. Vectors > > > and hash tables are a good early target. > > > > Hash tables? Ugh, what is wrong with the hash tables we have > > right now in GCC? > > Lots of boiler plate involving casting to void*. Some of that > boiler plate makes the optimizer less effective. Have you any numbers that back that up? Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 18:54 ` Jakub Jelinek @ 2012-04-09 21:15 ` Lawrence Crowl 0 siblings, 0 replies; 182+ messages in thread From: Lawrence Crowl @ 2012-04-09 21:15 UTC (permalink / raw) To: Jakub Jelinek Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Apr 09, 2012 at 11:51:56AM -0700, Lawrence Crowl wrote: >> On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote: >> > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: >> > > A build conversion to C++ is a precondition to any source change >> > > using C++, though the two could be bundled into one patch. In any >> > > event, I agree that the conversion needs to provide value. Vectors >> > > and hash tables are a good early target. >> > >> > Hash tables? Ugh, what is wrong with the hash tables we have >> > right now in GCC? >> >> Lots of boiler plate involving casting to void*. Some of that >> boiler plate makes the optimizer less effective. > > Have you any numbers that back that up? Not for the optimizer claim, as the conversion hasn't been done yet. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 18:52 ` Lawrence Crowl 2012-04-09 18:54 ` Jakub Jelinek @ 2012-04-10 11:09 ` Richard Guenther 2012-04-11 1:36 ` Lawrence Crowl 1 sibling, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-10 11:09 UTC (permalink / raw) To: Lawrence Crowl Cc: Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Mon, Apr 9, 2012 at 8:51 PM, Lawrence Crowl <crowl@google.com> wrote: > On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote: >> On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: >> > A build conversion to C++ is a precondition to any source change >> > using C++, though the two could be bundled into one patch. In any >> > event, I agree that the conversion needs to provide value. Vectors >> > and hash tables are a good early target. >> >> Hash tables? Ugh, what is wrong with the hash tables we have >> right now in GCC? > > Lots of boiler plate involving casting to void*. Some of that > boiler plate makes the optimizer less effective. Optimizers ignore pointer types, so that assertion cannot be true. Richard. > -- > Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 11:09 ` Richard Guenther @ 2012-04-11 1:36 ` Lawrence Crowl 2012-04-11 6:55 ` Jakub Jelinek 2012-04-11 9:32 ` Richard Guenther 0 siblings, 2 replies; 182+ messages in thread From: Lawrence Crowl @ 2012-04-11 1:36 UTC (permalink / raw) To: Richard Guenther Cc: Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/10/12, Richard Guenther <richard.guenther@gmail.com> wrote: > On Apr 9, 2012 Lawrence Crowl <crowl@google.com> wrote: > > On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote: > > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: > > > > A build conversion to C++ is a precondition to any source > > > > change using C++, though the two could be bundled into > > > > one patch. In any event, I agree that the conversion > > > > needs to provide value. Vectors and hash tables are a good > > > > early target. > > > > > > Hash tables? Ugh, what is wrong with the hash tables we have > > > right now in GCC? > > > > Lots of boiler plate involving casting to void*. Some of that > > boiler plate makes the optimizer less effective. > > Optimizers ignore pointer types, so that assertion cannot be true. The standard says they need not ignore them. I was thinking more about iterating over the contents. What in the current code is an indirect function call inside of a loop becomes mostly be inline functions in a C++ iterator style. The loop is now fully graspable by the optimizer. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 1:36 ` Lawrence Crowl @ 2012-04-11 6:55 ` Jakub Jelinek 2012-04-13 23:26 ` Dave Korn 2012-04-11 9:32 ` Richard Guenther 1 sibling, 1 reply; 182+ messages in thread From: Jakub Jelinek @ 2012-04-11 6:55 UTC (permalink / raw) To: Lawrence Crowl Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote: > The standard says they need not ignore them. > > I was thinking more about iterating over the contents. What in the > current code is an indirect function call inside of a loop becomes > mostly be inline functions in a C++ iterator style. The loop is now > fully graspable by the optimizer. That comes with its cost though, as we have hundreds of hashtables for various kinds of types, you'd get hundreds of different instantiations of the hash table code. hashtab.c is significantly more I-cache friendly than that. If a hash table doesn't need to be rehashed and the *with_hash routines are used, only the eq_f callback is called a few times (on each collision). Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 6:55 ` Jakub Jelinek @ 2012-04-13 23:26 ` Dave Korn 0 siblings, 0 replies; 182+ messages in thread From: Dave Korn @ 2012-04-13 23:26 UTC (permalink / raw) To: Jakub Jelinek Cc: Lawrence Crowl, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 11/04/2012 07:55, Jakub Jelinek wrote: > On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote: >> The standard says they need not ignore them. >> >> I was thinking more about iterating over the contents. What in the >> current code is an indirect function call inside of a loop becomes >> mostly be inline functions in a C++ iterator style. The loop is now >> fully graspable by the optimizer. > > That comes with its cost though, as we have hundreds of hashtables for > various kinds of types, you'd get hundreds of different instantiations of > the hash table code. hashtab.c is significantly more I-cache friendly > than that. Hmm, is that necessarily the case? GCC is big and I-caches are small; it could well be the case that hashtab.c gets evicted very regularly from the cache, and is only usually constant in it during the course of one individual loop. It wouldn't be any more expensive to map in any one hashtab C++ specialisation vs. another, and they'd all individually be of the same scale as the C hashtab.o code, so unless we have many nested loops that use one kind of hashtab in the outer loop and a different one in the inner loop, we could still end up pretty much where we started from in terms of I-cache usage. I expect profiling would immediately show up whether the two approaches made any significant difference or not, probably very visibly, but I wouldn't dismiss doing the experiment out-of-hand. If the inlining improvements exceed the extra cost of paging, switching to C++ would be justified. cheers, DaveK ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 1:36 ` Lawrence Crowl 2012-04-11 6:55 ` Jakub Jelinek @ 2012-04-11 9:32 ` Richard Guenther 1 sibling, 0 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-11 9:32 UTC (permalink / raw) To: Lawrence Crowl Cc: Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 3:35 AM, Lawrence Crowl <crowl@google.com> wrote: > On 4/10/12, Richard Guenther <richard.guenther@gmail.com> wrote: >> On Apr 9, 2012 Lawrence Crowl <crowl@google.com> wrote: >> > On 4/9/12, Jakub Jelinek <jakub@redhat.com> wrote: >> > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: >> > > > A build conversion to C++ is a precondition to any source >> > > > change using C++, though the two could be bundled into >> > > > one patch. In any event, I agree that the conversion >> > > > needs to provide value. Vectors and hash tables are a good >> > > > early target. >> > > >> > > Hash tables? Ugh, what is wrong with the hash tables we have >> > > right now in GCC? >> > >> > Lots of boiler plate involving casting to void*. Some of that >> > boiler plate makes the optimizer less effective. >> >> Optimizers ignore pointer types, so that assertion cannot be true. > > The standard says they need not ignore them. > > I was thinking more about iterating over the contents. What in the > current code is an indirect function call inside of a loop becomes > mostly be inline functions in a C++ iterator style. The loop is now > fully graspable by the optimizer. We already use C++ iterator "style" and there are nearly no indirect function calls involved (unless you use the walk_*_with_* routines, which I detest, and you get the same when you use C++ foreach () style). Richard. > > -- > Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 18:22 ` Jakub Jelinek 2012-04-09 18:52 ` Lawrence Crowl @ 2012-04-14 3:07 ` Chiheng Xu 1 sibling, 0 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 3:07 UTC (permalink / raw) To: Jakub Jelinek Cc: Lawrence Crowl, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 2:22 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote: >> A build conversion to C++ is a precondition to any source change >> using C++, though the two could be bundled into one patch. In any >> event, I agree that the conversion needs to provide value. Vectors >> and hash tables are a good early target. > > Hash tables? Ugh, what is wrong with the hash tables we have right now in > GCC? > He probably mean to wrap hash table in C++ class. -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 10:40 ` Richard Guenther 2012-04-09 17:56 ` Lawrence Crowl @ 2012-04-14 3:04 ` Chiheng Xu 2012-04-14 21:25 ` Lawrence Crowl 1 sibling, 1 reply; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 3:04 UTC (permalink / raw) To: Richard Guenther Cc: Lawrence Crowl, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Mon, Apr 9, 2012 at 6:40 PM, Richard Guenther <richard.guenther@gmail.com> wrote: >> >> Certainly there are cases where the type must be made more specific, >> and getting the wrong type here would necessarily be a dynamic check. >> However, the number of dynamic checks can be substantially reduced. >> To provide a specific example, suppose I have a common_decl *p and >> need to do extra work if it is a var_decl. >> >> do_general_work (p); >> if (var_decl *q = p->to_var ()) >> { >> do_var_work_1 (q); >> do_var_work_2 (q); >> do_var_work_3 (q); >> do_var_work_4 (q); >> } >> >> The only dynamic work is in the pointer conversion. All other >> function calls can be statically typed. > > Ok. But the above represents a completely different programming > style than what we use currently. We do > > if (is_var_decl (p)) > { > do_var_work_1 (p); > ... > } > > so what I was refering to was static errors we get when we are > able to promote function argument / return types to more specific > sub-classes. > What about this: if(is_var_decl(p)) { var_decl * p_var_decl = (var_decl *) p; do_var_work_1 (p_var_decl); }else if(is_type_decl(p)){ type_decl * p_type_decl = (type_decl *) p; do_type_work_2 (p_type_decl); }else if(is_field_decl(p)){ field_decl * p_field_decl = (field_decl *) p; do_field_work_3 (p_field_decl); } -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 3:04 ` Chiheng Xu @ 2012-04-14 21:25 ` Lawrence Crowl 0 siblings, 0 replies; 182+ messages in thread From: Lawrence Crowl @ 2012-04-14 21:25 UTC (permalink / raw) To: Chiheng Xu Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/13/12, Chiheng Xu <chiheng.xu@gmail.com> wrote: > On Apr 9, 2012, Richard Guenther <richard.guenther@gmail.com> wrote: >>> Certainly there are cases where the type must be made more specific, >>> and getting the wrong type here would necessarily be a dynamic check. >>> However, the number of dynamic checks can be substantially reduced. >>> To provide a specific example, suppose I have a common_decl *p and >>> need to do extra work if it is a var_decl. >>> >>> do_general_work (p); >>> if (var_decl *q = p->to_var ()) >>> { >>> do_var_work_1 (q); >>> do_var_work_2 (q); >>> do_var_work_3 (q); >>> do_var_work_4 (q); >>> } >>> >>> The only dynamic work is in the pointer conversion. All other >>> function calls can be statically typed. >> >> Ok. But the above represents a completely different programming >> style than what we use currently. We do >> >> if (is_var_decl (p)) >> { >> do_var_work_1 (p); >> ... >> } >> >> so what I was refering to was static errors we get when we are >> able to promote function argument / return types to more specific >> sub-classes. > > What about this: > if(is_var_decl(p)) { > var_decl * p_var_decl = (var_decl *) p; > do_var_work_1 (p_var_decl); > }else if(is_type_decl(p)){ > type_decl * p_type_decl = (type_decl *) p; > do_type_work_2 (p_type_decl); > }else if(is_field_decl(p)){ > field_decl * p_field_decl = (field_decl *) p; > do_field_work_3 (p_field_decl); > } That approach will certainly work, but makes the correctness of the assignment contingent on the condition being right. If the condition changes in appropriately, you can get a bug. Even so, I think what you suggest is a good intermediate step. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 12:04 ` Richard Guenther 2012-04-04 14:59 ` Diego Novillo 2012-04-04 17:54 ` Lawrence Crowl @ 2012-04-09 23:34 ` Xinliang David Li 2012-04-10 8:46 ` Jakub Jelinek 2012-04-10 11:14 ` Richard Guenther 2012-04-14 2:41 ` Chiheng Xu 3 siblings, 2 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-09 23:34 UTC (permalink / raw) To: Richard Guenther Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >> On 04/04/2012 11:06 AM, Richard Guenther wrote: >>> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined >>> by transitioning vec.h to a C++ template class, with proper GC support. >>> (not sure that I can veto anything - heh) >> >> I don't think I can veto anything, but I'll go on the record again >> saying that I don't think this entire plan is a good idea. Write a new >> project in C++? Absolutely. Convert a large existing one to a different >> language? A huge waste of time that will distract us for years from >> actual user-visible changes. > > I agree for the idea of converting all of GCC to C++ (whatever that means). > I disagree for the part making the internal infrastructure easier to use, > understand and maintain. Which means targeting mostly isolated sub-systems, > like vec.h (and other various containers), double-int.[ch] (and other various > way of representing and working with constants). Making tree or gimple a > C++ class with inheritance and whatever is indeed a huge waste of time > and existing developer ressources (that, if only because they have to adapt > and maintain two completely different code-bases over some time). > > I expect the GCC core to maintain written in C, compiled by C++. GCC's current C programming APIs (both browsing APIs and creator/factory APIs) are somewhat primitive and too low level. I expect switching to C++ can significantly make GCC more modern looking. It can greatly improve readability and productivity (for simplifying transformation and instrumentation development). C++ features should not be be abused (e.g., MI, VI etc), but we should not miss on basic C++ features. Class hierarchy is one such feature that is useful. Assuming we have two hierarchies for gcc: one for values rooted at ValExp, and one for gimple stmts rooted at GimpInst. 1) For IR browsing, *) all the macro accessors can be eliminated -- a big plus for debugging; *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) e.g. exp->as_component_ref().get_field() .. exp->as_mem_access().get_base() ... exp->as_mem_acesss().get_address() --> produces the address expression for memory access exp->as_mem_access().get_alias_handle () gimple_inst->serialize (&fixup_list) --> a virtual function overriden by actual instruction types that knows its byte code format. For experienced GCC developers, current APIs won't a problem at all -- but it does become a big minus for newbies and in the long run will hurt gcc community. 2) IR manipulation APIs -- the problem seems more serious. It seems GCC prefers low level APIs so that incremental update of derived data (control flow, SSA) can be easier -- but that does not have to be the case -- high level APIs can hide most of the update from the programmer. Example: Create a a simple assignment instruction from a load (this example comes from Asan implementation in gcc by Kostya) t = build1 (INDIRECT_REF, some_type, build1 (VIEW_CONVERT_EXPR, some_type, addr)); t = force_gimple_operand (t, &stmts, false, NULL_TREE); gimple_seq_add_seq (&seq, stmts); the_value = make_rename_temp (shadow_type, "__var_name"); g = gimple_build_assign (the_value, t); nm = make_ssa_name (the_value, g); gimple_assign_set_lhs (g, nm); This can be as simple as (by hiding the gimplification, ssa name creation etc) new_assign_insn = gimple::new_load_insn (INDIRECT_REF, some_type, addr_exp); new_assign_insn->get_lhs()->as_ssa_name()->get_val_decl()->setname("..."); The creator interface can also take a form that accepts the addr_insn that produces the address. Another example: Instrument a BB1 so that it is guarded: if (counts > sampling_rate) // BB0 { counts = 0; ORIGINAL BB1 code } // BB2 It can be as simple as the following: basic_block bb0, bb1; gimple_br_inst = gimple::new_cond_br (value:new_cmp_exp (....), bb1, /* taken branch* / &bb2, /* fall through */ &bb2, /* merge point */ &bb0 /* New predecessor */); reset_count = gimple:new_store_insn (..., bb1, insert_before); If the current APIs are used to do the coding, it will take how X times more API calls which is non-readable for human beings. thanks, David > >> I also find debugging C++ in gdb somewhat more annoying than debugging >> plain C, and at the moment I always go back to a stage1 compiler. > > Indeed - I'd be worried if my debugging efficiency decreases by more than 5%. > > Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 23:34 ` Xinliang David Li @ 2012-04-10 8:46 ` Jakub Jelinek 2012-04-10 12:26 ` Michael Matz ` (5 more replies) 2012-04-10 11:14 ` Richard Guenther 1 sibling, 6 replies; 182+ messages in thread From: Jakub Jelinek @ 2012-04-10 8:46 UTC (permalink / raw) To: Xinliang David Li Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: > Class hierarchy is one such feature that is useful. Assuming we have > two hierarchies for gcc: one for values rooted at ValExp, and one for > gimple stmts rooted at GimpInst. > > 1) For IR browsing, > *) all the macro accessors can be eliminated -- a big plus for debugging; Not that clear, if all the macros are replaced by tons of inline functions, the debugging experience can be actually significantly worse. Already some the inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH macro are extremely annoying from debugging POV. > *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) > > e.g. > exp->as_component_ref().get_field() .. > exp->as_mem_access().get_base() ... > exp->as_mem_acesss().get_address() --> produces the > address expression for memory access > exp->as_mem_access().get_alias_handle () > > gimple_inst->serialize (&fixup_list) --> a virtual > function overriden by actual instruction types that knows its byte > code format. That silently assumes we want to change basic GIMPLE/tree data structures to virtual classes, which is a significant change that has a significant cost as well. E.g. all such changed data structures grow by a virtual pointer field. Those data structures are heavily optimized for memory footprint. Not to mention it is very questionable if the above stuff is more readable than what we currently have. Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 8:46 ` Jakub Jelinek @ 2012-04-10 12:26 ` Michael Matz 2012-04-10 15:51 ` David Edelsohn 2012-04-10 16:12 ` Xinliang David Li 2012-04-10 16:23 ` Xinliang David Li ` (4 subsequent siblings) 5 siblings, 2 replies; 182+ messages in thread From: Michael Matz @ 2012-04-10 12:26 UTC (permalink / raw) To: Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc Hi, On Tue, 10 Apr 2012, Jakub Jelinek wrote: > > *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) > > > > e.g. > > exp->as_component_ref().get_field() .. > > exp->as_mem_access().get_base() ... > > exp->as_mem_acesss().get_address() --> produces the > > address expression for memory access > > exp->as_mem_access().get_alias_handle () > > > > gimple_inst->serialize (&fixup_list) --> a virtual > > function overriden by actual instruction types that knows its byte > > code format. > > That silently assumes we want to change basic GIMPLE/tree data structures > to virtual classes, which is a significant change that has a significant > cost as well. E.g. all such changed data structures grow by a virtual > pointer field. Those data structures are heavily optimized for memory > footprint. > Not to mention it is very questionable if the above stuff is more readable > than what we currently have. Actually it's not questionable. The above stuff is _horrible_. Ciao, Michael. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 12:26 ` Michael Matz @ 2012-04-10 15:51 ` David Edelsohn 2012-04-10 16:05 ` Gabriel Dos Reis 2012-04-10 16:12 ` Xinliang David Li 1 sibling, 1 reply; 182+ messages in thread From: David Edelsohn @ 2012-04-10 15:51 UTC (permalink / raw) To: Michael Matz Cc: Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, Diego Novillo, gcc On Tue, Apr 10, 2012 at 8:26 AM, Michael Matz <matz@suse.de> wrote: > Hi, > > On Tue, 10 Apr 2012, Jakub Jelinek wrote: > >> > *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> > >> > e.g. >> > exp->as_component_ref().get_field() .. >> > exp->as_mem_access().get_base() ... >> > exp->as_mem_acesss().get_address() --> produces the >> > address expression for memory access >> > exp->as_mem_access().get_alias_handle () >> > >> > gimple_inst->serialize (&fixup_list) --> a virtual >> > function overriden by actual instruction types that knows its byte >> > code format. >> >> That silently assumes we want to change basic GIMPLE/tree data structures >> to virtual classes, which is a significant change that has a significant >> cost as well. E.g. all such changed data structures grow by a virtual >> pointer field. Those data structures are heavily optimized for memory >> footprint. >> Not to mention it is very questionable if the above stuff is more readable >> than what we currently have. > > Actually it's not questionable. The above stuff is _horrible_. There seem to be at least four parts to this discussion about benefits of C++: 1) Object-oriented and class-based design 2) Optimization benefit or challenge 3) Debugging 4) C++ syntax Hopefully all will benefit and they all support one another, but they are not inherently linked and dependent upon each other. Developers who are used to C++ will be comfortable with / familiar with the syntax above and developers who are used to GCC's current syntax will not like the change. The real challenge is that there are many more developers familiar with C++ syntax than with GCC internals syntax. If we could allow each group their own view, life would be much better. Also, it will be more convenient to make this change incrementally, but the GCC community probably will not see much benefit until the transition is complete. That also means developers asserting benefits need to be realistic and separate their end vision from what actually can be achieved in the short and medium term. - David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 15:51 ` David Edelsohn @ 2012-04-10 16:05 ` Gabriel Dos Reis 2012-04-10 16:13 ` Diego Novillo 0 siblings, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-10 16:05 UTC (permalink / raw) To: David Edelsohn Cc: Michael Matz, Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, Diego Novillo, gcc On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn <dje.gcc@gmail.com> wrote: > Also, it will be more convenient to make this change incrementally, > but the GCC community probably will not see much benefit until the > transition is complete. That also means developers asserting benefits > need to be realistic and separate their end vision from what actually > can be achieved in the short and medium term. Fully agreed. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:05 ` Gabriel Dos Reis @ 2012-04-10 16:13 ` Diego Novillo 2012-04-11 9:17 ` Richard Guenther 0 siblings, 1 reply; 182+ messages in thread From: Diego Novillo @ 2012-04-10 16:13 UTC (permalink / raw) To: Gabriel Dos Reis Cc: David Edelsohn, Michael Matz, Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, gcc On 4/10/12 12:05 PM, Gabriel Dos Reis wrote: > On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn<dje.gcc@gmail.com> wrote: > >> Also, it will be more convenient to make this change incrementally, >> but the GCC community probably will not see much benefit until the >> transition is complete. That also means developers asserting benefits >> need to be realistic and separate their end vision from what actually >> can be achieved in the short and medium term. > > Fully agreed. Indeed. My personal take on this is that it is going to be a gradual (for some glacially slow) change. I think that debating these points in the abstract gains us very little. Instead, each patch and/or API re-design should be discussed individually. Patches will have specific metrics that can be collected. API changes will be more of a bike shed, but it will at least lead to more concrete discussions. The end goal for me is simple: modernize the code base to make it more attractive to future developers. There is some balancing act to be done, in that we should cater to the existing developers as well. But it is easier for us, we already know the code and can influence the transition. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:13 ` Diego Novillo @ 2012-04-11 9:17 ` Richard Guenther 2012-04-11 16:35 ` Xinliang David Li 0 siblings, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-11 9:17 UTC (permalink / raw) To: Diego Novillo Cc: Gabriel Dos Reis, David Edelsohn, Michael Matz, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, gcc On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo <dnovillo@google.com> wrote: > On 4/10/12 12:05 PM, Gabriel Dos Reis wrote: >> >> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn<dje.gcc@gmail.com> >> wrote: >> >>> Also, it will be more convenient to make this change incrementally, >>> but the GCC community probably will not see much benefit until the >>> transition is complete. That also means developers asserting benefits >>> need to be realistic and separate their end vision from what actually >>> can be achieved in the short and medium term. >> >> >> Fully agreed. > > > Indeed. My personal take on this is that it is going to be a gradual (for > some glacially slow) change. I think that debating these points in the > abstract gains us very little. > > Instead, each patch and/or API re-design should be discussed individually. > Patches will have specific metrics that can be collected. API changes will > be more of a bike shed, but it will at least lead to more concrete > discussions. > > The end goal for me is simple: modernize the code base to make it more > attractive to future developers. There is some balancing act to be done, in > that we should cater to the existing developers as well. But it is easier > for us, we already know the code and can influence the transition. I think it's important to let the C folks slowly accomodate with C++, thus do not jump-start with even possibly questionable API changes. There are a _lot_ of "obvious" candidates that are even well contained (thus no fear of a can of partial-C++ transitions) like the various containers we use and APIs which are not in wide-spread use, like the cgraph API (which Honza is about to turn upside down). I also agree that exp->as_component_ref().get_field() is exceptionally bad. Both for the compile-time of the above expressions (three function calls that all are need to be inlined?!) and readability. And I've spent quite some time with various C++ codebases. None was as ugly as the above (and yes, I consider the LLVM C++ style exceptionally ugly as well). So, please no, do not even try to start the flamewar on C++-ifying trees or gimple. Not in the next three years at least. Propose a nice and usable C++ _plugin_ API that encapsulates trees and GIMPLE. _Then_ we can talk. Thanks, Richard. > > Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 9:17 ` Richard Guenther @ 2012-04-11 16:35 ` Xinliang David Li 0 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 16:35 UTC (permalink / raw) To: Richard Guenther Cc: Diego Novillo, Gabriel Dos Reis, David Edelsohn, Michael Matz, Jakub Jelinek, Bernd Schmidt, gcc On Wed, Apr 11, 2012 at 2:16 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Tue, Apr 10, 2012 at 6:13 PM, Diego Novillo <dnovillo@google.com> wrote: >> On 4/10/12 12:05 PM, Gabriel Dos Reis wrote: >>> >>> On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn<dje.gcc@gmail.com> >>> wrote: >>> >>>> Also, it will be more convenient to make this change incrementally, >>>> but the GCC community probably will not see much benefit until the >>>> transition is complete. That also means developers asserting benefits >>>> need to be realistic and separate their end vision from what actually >>>> can be achieved in the short and medium term. >>> >>> >>> Fully agreed. >> >> >> Indeed. My personal take on this is that it is going to be a gradual (for >> some glacially slow) change. I think that debating these points in the >> abstract gains us very little. >> >> Instead, each patch and/or API re-design should be discussed individually. >> Patches will have specific metrics that can be collected. API changes will >> be more of a bike shed, but it will at least lead to more concrete >> discussions. >> >> The end goal for me is simple: modernize the code base to make it more >> attractive to future developers. There is some balancing act to be done, in >> that we should cater to the existing developers as well. But it is easier >> for us, we already know the code and can influence the transition. > > I think it's important to let the C folks slowly accomodate with C++, thus > do not jump-start with even possibly questionable API changes. There > are a _lot_ of "obvious" candidates that are even well contained (thus no > fear of a can of partial-C++ transitions) like the various containers we use > and APIs which are not in wide-spread use, like the cgraph API (which Honza > is about to turn upside down). I think this is a good plan to move forward -- I also agree cgraph is a good candidate. Other candidates include optimization driver/pass manager, IR text dumper, persistent IR dumper/reader etc. > > I also agree that > > exp->as_component_ref().get_field() > > is exceptionally bad. Both for the compile-time of the above expressions > (three function calls that all are need to be inlined?!) I find this less convincing -- the compile time cost should be very small -- and it may also allow more compile time saving: X* derived = p->asX(); // runtime assertion done once. derived->do_x_1 (); derived->do_x_2 (); .... As compared with a fat interface case: G* generic = p; DO_X_1 (generic); // runtime assertion needed DO_X_2 (generic); // runtime assertion needed ... > and readability. This is again very subjective -- and the style can be hidden under a macro. The benefit of using C++ API is not for the style change, but for proper interface partition. > And I've spent quite some time with various C++ codebases. None was > as ugly as the above (and yes, I consider the LLVM C++ style exceptionally > ugly as well). well, many people will probably disagree here. > > So, please no, do not even try to start the flamewar on C++-ifying trees > or gimple. Not in the next three years at least. > > Propose a nice and usable C++ _plugin_ API that encapsulates trees and > GIMPLE. _Then_ we can talk. I think keeping the core APIs in C is fine even though there are more work to make the current C APIs more user friendly. It might be a good idea to move the core APIs into a separate directory. thanks, David > > Thanks, > Richard. > >> >> Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 12:26 ` Michael Matz 2012-04-10 15:51 ` David Edelsohn @ 2012-04-10 16:12 ` Xinliang David Li 2012-04-10 16:24 ` Michael Matz 1 sibling, 1 reply; 182+ messages in thread From: Xinliang David Li @ 2012-04-10 16:12 UTC (permalink / raw) To: Michael Matz Cc: Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 5:26 AM, Michael Matz <matz@suse.de> wrote: > Hi, > > On Tue, 10 Apr 2012, Jakub Jelinek wrote: > >> > *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> > >> > e.g. >> > exp->as_component_ref().get_field() .. >> > exp->as_mem_access().get_base() ... >> > exp->as_mem_acesss().get_address() --> produces the >> > address expression for memory access >> > exp->as_mem_access().get_alias_handle () >> > >> > gimple_inst->serialize (&fixup_list) --> a virtual >> > function overriden by actual instruction types that knows its byte >> > code format. >> >> That silently assumes we want to change basic GIMPLE/tree data structures >> to virtual classes, which is a significant change that has a significant >> cost as well. E.g. all such changed data structures grow by a virtual >> pointer field. Those data structures are heavily optimized for memory >> footprint. >> Not to mention it is very questionable if the above stuff is more readable >> than what we currently have. > > Actually it's not questionable. The above stuff is _horrible_. > Specifics please. It is _horrible_ because you are more used to the existing way and the new style does not match your taste or they are very hard to understand and use? David > > Ciao, > Michael. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:12 ` Xinliang David Li @ 2012-04-10 16:24 ` Michael Matz 2012-04-10 17:08 ` Xinliang David Li ` (3 more replies) 0 siblings, 4 replies; 182+ messages in thread From: Michael Matz @ 2012-04-10 16:24 UTC (permalink / raw) To: Xinliang David Li Cc: Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc [-- Attachment #1: Type: TEXT/PLAIN, Size: 986 bytes --] Hi, On Tue, 10 Apr 2012, Xinliang David Li wrote: > >> > Â Â Â Â Â Â exp->as_component_ref().get_field() .. > > Actually it's not questionable. Â The above stuff is _horrible_. > > Specifics please. It is _horrible_ because you are more used to the > existing way and the new style does not match your taste or they are > very hard to understand and use? Your style (I wouldn't call it The New Style) is visually distracting, and therefore harder to understand and use, longer to write and full of syntactic noise without any whitespace. Quite frankly, how anyone could ever say that exp->as_component_ref().get_field() is easier to read/write/use than GET_FIELD_DECL (exp) (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without all-caps, is completely beyond me. I pretty much hope that we never see the ugliness of the first way in GCCs code base. Even in C++ it's possible to write non-spaghetti code. Ciao, Michael. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:24 ` Michael Matz @ 2012-04-10 17:08 ` Xinliang David Li 2012-04-10 17:29 ` Torvald Riegel ` (2 subsequent siblings) 3 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-10 17:08 UTC (permalink / raw) To: Michael Matz Cc: Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 9:24 AM, Michael Matz <matz@suse.de> wrote: > Hi, > > On Tue, 10 Apr 2012, Xinliang David Li wrote: > >> >> > exp->as_component_ref().get_field() .. > >> > Actually it's not questionable. The above stuff is _horrible_. >> >> Specifics please. It is _horrible_ because you are more used to the >> existing way and the new style does not match your taste or they are >> very hard to understand and use? > > Your style (I wouldn't call it The New Style) is visually distracting, and > therefore harder to understand and use, longer to write and full of > syntactic noise without any whitespace. Quite frankly, how anyone could > ever say that > > exp->as_component_ref().get_field() > > is easier to read/write/use than > > GET_FIELD_DECL (exp) > > (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without > all-caps, is completely beyond me. I pretty much hope that we never see > the ugliness of the first way in GCCs code base. Even in C++ it's > possible to write non-spaghetti code. As you said, this is still about taste -- and I agree the preference to style is totally subjective. Changing to C++ style API will needed to be justified by other things such as better static type checking, elimination of unnecessary opcode checking when the most derived type is known in the context etc. Defining macros like GET_FIELD_DECL to replace TREE_OPERAND(...) is an improvement by itself, but it can not prevent user from directly using TREE_OPERAND(x,...) directly. David > > > Ciao, > Michael. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:24 ` Michael Matz 2012-04-10 17:08 ` Xinliang David Li @ 2012-04-10 17:29 ` Torvald Riegel 2012-04-10 18:00 ` Eric Botcazou 2012-04-11 9:24 ` Richard Guenther 2012-04-10 17:48 ` DJ Delorie 2012-04-10 19:21 ` Dave Korn 3 siblings, 2 replies; 182+ messages in thread From: Torvald Riegel @ 2012-04-10 17:29 UTC (permalink / raw) To: Michael Matz Cc: Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, 2012-04-10 at 18:24 +0200, Michael Matz wrote: > Hi, > > On Tue, 10 Apr 2012, Xinliang David Li wrote: > > > >> > exp->as_component_ref().get_field() .. > > > > Actually it's not questionable. The above stuff is _horrible_. > > > > Specifics please. It is _horrible_ because you are more used to the > > existing way and the new style does not match your taste or they are > > very hard to understand and use? > > Your style (I wouldn't call it The New Style) is visually distracting, and > therefore harder to understand and use, longer to write and full of > syntactic noise without any whitespace. Quite frankly, how anyone could > ever say that > > exp->as_component_ref().get_field() > > is easier to read/write/use than > > GET_FIELD_DECL (exp) > > (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without > all-caps, is completely beyond me. I pretty much hope that we never see > the ugliness of the first way in GCCs code base. Even in C++ it's > possible to write non-spaghetti code. I don't see how this is spaghetti code. It it slightly longer, but that's just the case in this specific example. Think about programmers new to GCC for a second, and about code completion tools. It seems to me that with such a tool it's much easier to navigate from exp to the field, than having to scan through a much larger number of accessor functions / macros (GET_*). The former example starts at the source (exp) and yields/"builds" the result; the latter names some function and then says applies it to the source. Why is the former so much worse? To me, the former's structure is easier to see, and if I would have to put the spaghetti tag on something, then the latter. Also, how do you envision code completion to work with the latter? Type exp first, and then have it show which functions take arguments compatible with exp, and then replace it? If a programmer doesn't remember all of the GCC APIs, code completion tools are very convenient. Torvald ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 17:29 ` Torvald Riegel @ 2012-04-10 18:00 ` Eric Botcazou 2012-04-10 19:56 ` Torvald Riegel 2012-04-11 9:24 ` Richard Guenther 1 sibling, 1 reply; 182+ messages in thread From: Eric Botcazou @ 2012-04-10 18:00 UTC (permalink / raw) To: gcc, Torvald Riegel Cc: Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo > Think about programmers new to GCC for a second, and about code > completion tools. It seems to me that with such a tool it's much easier > to navigate from exp to the field, than having to scan through a much > larger number of accessor functions / macros (GET_*). The former > example starts at the source (exp) and yields/"builds" the result; the > latter names some function and then says applies it to the source. Why > is the former so much worse? Because it takes x3 characters/x3 time to type/x3 slots in your memory? > To me, the former's structure is easier to see, and if I would have to put > the spaghetti tag on something, then the latter. Spaghetti isn't really the best wording, gratuitous obfuscation is better. :-) -- Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 18:00 ` Eric Botcazou @ 2012-04-10 19:56 ` Torvald Riegel 2012-04-10 21:13 ` Eric Botcazou 0 siblings, 1 reply; 182+ messages in thread From: Torvald Riegel @ 2012-04-10 19:56 UTC (permalink / raw) To: Eric Botcazou Cc: gcc, Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo On Tue, 2012-04-10 at 19:59 +0200, Eric Botcazou wrote: > > Think about programmers new to GCC for a second, and about code > > completion tools. It seems to me that with such a tool it's much easier > > to navigate from exp to the field, than having to scan through a much > > larger number of accessor functions / macros (GET_*). The former > > example starts at the source (exp) and yields/"builds" the result; the > > latter names some function and then says applies it to the source. Why > > is the former so much worse? > > Because it takes x3 characters/x3 time to type/x3 slots in your memory? I hope this is meant to be ironic. Or are you really saying that the number of characters determines how quickly/easily a brain can remember/find something like an API item/keyword/...? If so, and if we assume that GET, FIELD, and DECL are the most likely (sub-)parts of function names shouldn't it be G_F_D (exp) then? ;) Torvald ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 19:56 ` Torvald Riegel @ 2012-04-10 21:13 ` Eric Botcazou 2012-04-10 21:29 ` Torvald Riegel 0 siblings, 1 reply; 182+ messages in thread From: Eric Botcazou @ 2012-04-10 21:13 UTC (permalink / raw) To: Torvald Riegel Cc: gcc, Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo > Or are you really saying that the number of characters determines how > quickly/easily a brain can remember/find something like an API > item/keyword/...? If so, and if we assume that GET, FIELD, and DECL are > the most likely (sub-)parts of function names shouldn't it be G_F_D > (exp) then? ;) The number of tokens. GET_FIELD_DECL has 2 tokens (GET and FIELD_DECL) while exp->as_component_ref().get_field() has 3x more. -- Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 21:13 ` Eric Botcazou @ 2012-04-10 21:29 ` Torvald Riegel 2012-04-10 23:15 ` Eric Botcazou 0 siblings, 1 reply; 182+ messages in thread From: Torvald Riegel @ 2012-04-10 21:29 UTC (permalink / raw) To: Eric Botcazou Cc: gcc, Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo On Tue, 2012-04-10 at 23:12 +0200, Eric Botcazou wrote: > > Or are you really saying that the number of characters determines how > > quickly/easily a brain can remember/find something like an API > > item/keyword/...? If so, and if we assume that GET, FIELD, and DECL are > > the most likely (sub-)parts of function names shouldn't it be G_F_D > > (exp) then? ;) > > The number of tokens. GET_FIELD_DECL has 2 tokens (GET and FIELD_DECL) while > exp->as_component_ref().get_field() has 3x more. I can't derive a definition of "token" from your example that seems meaningful. It can't be parser tokens I assume, because you split GET_FIELD_DECL (but why in 2 not 3?). Same for "exp->..."; where are the 8 tokens? (Or did you in fact mean 3 times as much, so 6?). In any case, that suggests that the tokenization you had in mind is not obvious (or perhaps just not to me). Following another comment in the thread, what are the concepts you'd like to be included, and which don't you want to be included? Next step, is this actually tied to saying FOO(exp) vs. exp->foo(), or could your favorite (compression of) concepts be as well expressed with the latter? ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 21:29 ` Torvald Riegel @ 2012-04-10 23:15 ` Eric Botcazou 2012-04-11 20:57 ` Torvald Riegel 0 siblings, 1 reply; 182+ messages in thread From: Eric Botcazou @ 2012-04-10 23:15 UTC (permalink / raw) To: Torvald Riegel Cc: gcc, Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo > I can't derive a definition of "token" from your example that seems > meaningful. It can't be parser tokens I assume, because you split > GET_FIELD_DECL (but why in 2 not 3?). FIELD_DECL is a single object, see tree.def. > Following another comment in the thread, what are the concepts you'd > like to be included, and which don't you want to be included? Next > step, is this actually tied to saying FOO(exp) vs. exp->foo(), or could > your favorite (compression of) concepts be as well expressed with the > latter? I'm entirely of DJ's opinion here: C vs C++ is not the same argument as style A vs style B. I don't think that it would be desirable to fundamentally change the current style, at least to start adding -> and . all over the place. -- Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 23:15 ` Eric Botcazou @ 2012-04-11 20:57 ` Torvald Riegel 2012-04-11 21:15 ` Eric Botcazou 0 siblings, 1 reply; 182+ messages in thread From: Torvald Riegel @ 2012-04-11 20:57 UTC (permalink / raw) To: Eric Botcazou Cc: gcc, Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo On Wed, 2012-04-11 at 01:14 +0200, Eric Botcazou wrote: > > I can't derive a definition of "token" from your example that seems > > meaningful. It can't be parser tokens I assume, because you split > > GET_FIELD_DECL (but why in 2 not 3?). > > FIELD_DECL is a single object, see tree.def. So, you only know it's 2 tokens once you know all of tree.def? I'm aware that this is just some arbitrary example, but I believe this actually strengthens the concern I had. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 20:57 ` Torvald Riegel @ 2012-04-11 21:15 ` Eric Botcazou 2012-04-11 21:43 ` Torvald Riegel 2012-04-13 23:33 ` Dave Korn 0 siblings, 2 replies; 182+ messages in thread From: Eric Botcazou @ 2012-04-11 21:15 UTC (permalink / raw) To: Torvald Riegel Cc: gcc, Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo > So, you only know it's 2 tokens once you know all of tree.def? I'm > aware that this is just some arbitrary example, but I believe this > actually strengthens the concern I had. Well, if you don't know of FIELD_DECL, you won't go very far, really. -- Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 21:15 ` Eric Botcazou @ 2012-04-11 21:43 ` Torvald Riegel 2012-04-13 23:33 ` Dave Korn 1 sibling, 0 replies; 182+ messages in thread From: Torvald Riegel @ 2012-04-11 21:43 UTC (permalink / raw) To: Eric Botcazou Cc: gcc, Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo On Wed, 2012-04-11 at 23:13 +0200, Eric Botcazou wrote: > > So, you only know it's 2 tokens once you know all of tree.def? I'm > > aware that this is just some arbitrary example, but I believe this > > actually strengthens the concern I had. > > Well, if you don't know of FIELD_DECL, you won't go very far, really. We are discussing a general style here, not this arbitrary example. (If I am mistakenly assuming that, sorry; but then your original comparison doesn't seem to be fair because you compare a shortcut against a verbose form). So assume the general case, GET_FOO_BAR (exp). Is this about the BAR of FOO, FOO of BAR, or FOOBAR? If we have two concepts named FOOBAR for different arguments, do we need GET_FOO_BAR_THIS and GET_FOO_BAR_THAT? Point is, if there is no context that partitions items, you have to name them differently, and you get less locality and reuse when thinking about something. That's for the long tail of course, shortcuts for the most common stuff can still be used. That's at least what I was commenting on. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 21:15 ` Eric Botcazou 2012-04-11 21:43 ` Torvald Riegel @ 2012-04-13 23:33 ` Dave Korn 1 sibling, 0 replies; 182+ messages in thread From: Dave Korn @ 2012-04-13 23:33 UTC (permalink / raw) To: Eric Botcazou Cc: Torvald Riegel, gcc, Michael Matz, Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo On 11/04/2012 22:13, Eric Botcazou wrote: >> So, you only know it's 2 tokens once you know all of tree.def? I'm >> aware that this is just some arbitrary example, but I believe this >> actually strengthens the concern I had. > > Well, if you don't know of FIELD_DECL, you won't go very far, really. > But still, wouldn't it be nice and enhance clarity to be able to use a different character/token between GET and FIELD_DECL than between FIELD and DECL? (Anyway, I still think we should start by just redefining GET_FIELD_DECL et. al. as C++ inline functions - or macros that invoke C++ inline functions, or whatever else that works better for whatever reason, regardless of the implementation details - and let the existing code continue to use them in exactly the same way as before.) cheers, DaveK ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 17:29 ` Torvald Riegel 2012-04-10 18:00 ` Eric Botcazou @ 2012-04-11 9:24 ` Richard Guenther 2012-04-11 12:58 ` Torvald Riegel 1 sibling, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-11 9:24 UTC (permalink / raw) To: Torvald Riegel Cc: Michael Matz, Xinliang David Li, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote: > On Tue, 2012-04-10 at 18:24 +0200, Michael Matz wrote: >> Hi, >> >> On Tue, 10 Apr 2012, Xinliang David Li wrote: >> >> > >> > exp->as_component_ref().get_field() .. >> >> > > Actually it's not questionable. The above stuff is _horrible_. >> > >> > Specifics please. It is _horrible_ because you are more used to the >> > existing way and the new style does not match your taste or they are >> > very hard to understand and use? >> >> Your style (I wouldn't call it The New Style) is visually distracting, and >> therefore harder to understand and use, longer to write and full of >> syntactic noise without any whitespace. Quite frankly, how anyone could >> ever say that >> >> exp->as_component_ref().get_field() >> >> is easier to read/write/use than >> >> GET_FIELD_DECL (exp) >> >> (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without >> all-caps, is completely beyond me. I pretty much hope that we never see >> the ugliness of the first way in GCCs code base. Even in C++ it's >> possible to write non-spaghetti code. > > I don't see how this is spaghetti code. It it slightly longer, but > that's just the case in this specific example. > > Think about programmers new to GCC for a second, and about code > completion tools. Honestly I care 1000 times more for existing GCC developers. Before new programmers will have an easier time with GCC _existing_ GCC developers will have to spend at least two GCC release cycles (that's very optimistic) turning the GCC codebase upside-down. Every existing GCC developer you lose on that way will slow down that process and for every existing GCC developer you probably need more that one "new" GCC developer starting. It's very easy for me to do the math and conclude that losing even _one_ experienced existing GCC developer makes this whole transition-to-C++ thing a non-starter. > It seems to me that with such a tool it's much easier > to navigate from exp to the field, than having to scan through a much > larger number of accessor functions / macros (GET_*). The former > example starts at the source (exp) and yields/"builds" the result; the > latter names some function and then says applies it to the source. Why > is the former so much worse? To me, the former's structure is easier to > see, and if I would have to put the spaghetti tag on something, then the > latter. Sounds more like missed features or bugs in the tools you use. Heh, after all our complaints that C++ will be harder to debug are deflected to "that are gdb missing features / bugs". So - file bugs against Eclipse (or whatever new and shiny programmers use these days), that it does not work well with a codebase like GCC. Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 9:24 ` Richard Guenther @ 2012-04-11 12:58 ` Torvald Riegel 2012-04-11 13:13 ` Richard Guenther ` (6 more replies) 0 siblings, 7 replies; 182+ messages in thread From: Torvald Riegel @ 2012-04-11 12:58 UTC (permalink / raw) To: Richard Guenther Cc: Michael Matz, Xinliang David Li, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: > On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote: > > Think about programmers new to GCC for a second, and about code > > completion tools. > > Honestly I care 1000 times more for existing GCC developers. Before > new programmers will have an easier time with GCC _existing_ GCC > developers will have to spend at least two GCC release cycles (that's > very optimistic) turning the GCC codebase upside-down. Every > existing GCC developer you lose on that way will slow down that > process and for every existing GCC developer you probably need more > that one "new" GCC developer starting. > > It's very easy for me to do the math and conclude that losing even _one_ > experienced existing GCC developer makes this whole transition-to-C++ > thing a non-starter. I agree that less work-force in the transition would be a problem. But is C++ (perceived to be) so bad that it would make people change their jobs? I mean, we're not talking about the experienced hobbyists here, or are we? However, the concern you raised is only one part of the problem. The other is that, put in a simplified way, GCC is competing with LLVM about new and/or non-fulltime-compiler developers. For me, it looks like LLVM is more appealing to them, and I believe part of the reason for that is the codebase. Now, how many release cycles do we have until LLVM is basically good enough to be used as a distro compiler (e.g., until code quality and confidence in bug freedom is sufficiently similar)? If we haven't ensured that GCC is appealing by this time, why should new programmers then start considering GCC and not just go by default to LLVM? > > > It seems to me that with such a tool it's much easier > > to navigate from exp to the field, than having to scan through a much > > larger number of accessor functions / macros (GET_*). The former > > example starts at the source (exp) and yields/"builds" the result; the > > latter names some function and then says applies it to the source. Why > > is the former so much worse? To me, the former's structure is easier to > > see, and if I would have to put the spaghetti tag on something, then the > > latter. > > Sounds more like missed features or bugs in the tools you use. Heh, > after all our complaints that C++ will be harder to debug are deflected > to "that are gdb missing features / bugs". So - file bugs against Eclipse > (or whatever new and shiny programmers use these days), that it does > not work well with a codebase like GCC. Please don't dismiss this so easily. Of course this is just an example and nothing major, but I believe many people will use tab completion on the shell, for example, and code completion is really similar. On the shell, or with paths names, you start with typing something, then can navigate from this context you provided. That just works better when you say context->function instead of function(context). And I'm not a cognitive psychologist, but to me, seeing the context first when reading left-to-right is also slightly easier to read. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:58 ` Torvald Riegel @ 2012-04-11 13:13 ` Richard Guenther 2012-04-11 13:23 ` Gabriel Dos Reis ` (2 more replies) [not found] ` <12130397.ZsTVnyYbKR@pawels> ` (5 subsequent siblings) 6 siblings, 3 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-11 13:13 UTC (permalink / raw) To: Torvald Riegel Cc: Michael Matz, Xinliang David Li, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote: > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: >> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote: >> > Think about programmers new to GCC for a second, and about code >> > completion tools. >> >> Honestly I care 1000 times more for existing GCC developers. Before >> new programmers will have an easier time with GCC _existing_ GCC >> developers will have to spend at least two GCC release cycles (that's >> very optimistic) turning the GCC codebase upside-down. Every >> existing GCC developer you lose on that way will slow down that >> process and for every existing GCC developer you probably need more >> that one "new" GCC developer starting. >> >> It's very easy for me to do the math and conclude that losing even _one_ >> experienced existing GCC developer makes this whole transition-to-C++ >> thing a non-starter. > > I agree that less work-force in the transition would be a problem. But > is C++ (perceived to be) so bad that it would make people change their > jobs? I mean, we're not talking about the experienced hobbyists here, > or are we? Until some company puts money behind converting to C++ then yes, it's the hobbyists (or the non-hobbyists in their spare time). > However, the concern you raised is only one part of the problem. The > other is that, put in a simplified way, GCC is competing with LLVM about > new and/or non-fulltime-compiler developers. For me, it looks like LLVM > is more appealing to them, and I believe part of the reason for that is > the codebase. > Now, how many release cycles do we have until LLVM is basically good > enough to be used as a distro compiler (e.g., until code quality and > confidence in bug freedom is sufficiently similar)? If we haven't > ensured that GCC is appealing by this time, why should new programmers > then start considering GCC and not just go by default to LLVM? If you look at the existing developer base then the majority of it is paid. And frankly while empolyers may listen to their employees, switching from GCC to LLVM is not something they'd do based on a C++ vs. C implementation language (but maybe based on availability of consulting services or new employees or viability of using LLVM for weird architectures or simply based on customer demand). >> >> > It seems to me that with such a tool it's much easier >> > to navigate from exp to the field, than having to scan through a much >> > larger number of accessor functions / macros (GET_*). The former >> > example starts at the source (exp) and yields/"builds" the result; the >> > latter names some function and then says applies it to the source. Why >> > is the former so much worse? To me, the former's structure is easier to >> > see, and if I would have to put the spaghetti tag on something, then the >> > latter. >> >> Sounds more like missed features or bugs in the tools you use. Heh, >> after all our complaints that C++ will be harder to debug are deflected >> to "that are gdb missing features / bugs". So - file bugs against Eclipse >> (or whatever new and shiny programmers use these days), that it does >> not work well with a codebase like GCC. > > Please don't dismiss this so easily. Of course this is just an example > and nothing major, but I believe many people will use tab completion on > the shell, for example, and code completion is really similar. On the > shell, or with paths names, you start with typing something, then can > navigate from this context you provided. That just works better when > you say context->function instead of function(context). > And I'm not a cognitive psychologist, but to me, seeing the context > first when reading left-to-right is also slightly easier to read. Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z) because operator precedence is visible. Similar for doit (a, b) compared to a.doit (b) (or b.doit (a) - what preference is there for two inputs?). So you likely end up with a mix anyway. Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 13:13 ` Richard Guenther @ 2012-04-11 13:23 ` Gabriel Dos Reis 2012-04-11 14:19 ` Torvald Riegel 2012-04-11 17:24 ` Xinliang David Li 2 siblings, 0 replies; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-11 13:23 UTC (permalink / raw) To: Richard Guenther Cc: Torvald Riegel, Michael Matz, Xinliang David Li, Jakub Jelinek, Bernd Schmidt, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 8:13 AM, Richard Guenther <richard.guenther@gmail.com> wrote: >> Please don't dismiss this so easily. Of course this is just an example >> and nothing major, but I believe many people will use tab completion on >> the shell, for example, and code completion is really similar. On the >> shell, or with paths names, you start with typing something, then can >> navigate from this context you provided. That just works better when >> you say context->function instead of function(context). >> And I'm not a cognitive psychologist, but to me, seeing the context >> first when reading left-to-right is also slightly easier to read. > > Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z) > because operator precedence is visible. that might be true but I do not think C++ wants you to write x.add(y).mult(z). -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 13:13 ` Richard Guenther 2012-04-11 13:23 ` Gabriel Dos Reis @ 2012-04-11 14:19 ` Torvald Riegel 2012-04-11 17:24 ` Xinliang David Li 2 siblings, 0 replies; 182+ messages in thread From: Torvald Riegel @ 2012-04-11 14:19 UTC (permalink / raw) To: Richard Guenther Cc: Michael Matz, Xinliang David Li, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, 2012-04-11 at 15:13 +0200, Richard Guenther wrote: > On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote: > > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: > >> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote: > >> > Think about programmers new to GCC for a second, and about code > >> > completion tools. > >> > >> Honestly I care 1000 times more for existing GCC developers. Before > >> new programmers will have an easier time with GCC _existing_ GCC > >> developers will have to spend at least two GCC release cycles (that's > >> very optimistic) turning the GCC codebase upside-down. Every > >> existing GCC developer you lose on that way will slow down that > >> process and for every existing GCC developer you probably need more > >> that one "new" GCC developer starting. > >> > >> It's very easy for me to do the math and conclude that losing even _one_ > >> experienced existing GCC developer makes this whole transition-to-C++ > >> thing a non-starter. > > > > I agree that less work-force in the transition would be a problem. But > > is C++ (perceived to be) so bad that it would make people change their > > jobs? I mean, we're not talking about the experienced hobbyists here, > > or are we? > > Until some company puts money behind converting to C++ then yes, > it's the hobbyists (or the non-hobbyists in their spare time). That is not what I said. The question I raised is whether a change to C++ aimed at growing the developer base would actually make full-time GCC developers change their jobs. What you are questioning is whether a single company would make itself responsible for the conversion. This is two different questions. And elsewhere in the thread, you assert that if the conversion happened, other developers would stop working on it (i.e., my question above). If this would indeed be the case, nobody would fulfill your request (money behind the conversion). So let's look at the first one first. > > > However, the concern you raised is only one part of the problem. The > > other is that, put in a simplified way, GCC is competing with LLVM about > > new and/or non-fulltime-compiler developers. For me, it looks like LLVM > > is more appealing to them, and I believe part of the reason for that is > > the codebase. > > Now, how many release cycles do we have until LLVM is basically good > > enough to be used as a distro compiler (e.g., until code quality and > > confidence in bug freedom is sufficiently similar)? If we haven't > > ensured that GCC is appealing by this time, why should new programmers > > then start considering GCC and not just go by default to LLVM? > > If you look at the existing developer base then the majority of it is paid. > And frankly while empolyers may listen to their employees, switching > from GCC to LLVM is not something they'd do based on a C++ vs. C > implementation language (but maybe based on availability of consulting > services or new employees or viability of using LLVM for weird architectures > or simply based on customer demand). Makes sense. But you also say that a switch in the language doesn't really matter for paid developers (or their employers), so why is there then such a strong opposition towards a switch? (assuming that the switch might have benefits to new developers..) Also, AFAICT, LLVM is attracting more new paid developers than GCC, or not? For them, they don't have to switch from GCC to LLVM, they simply don't start with GCC. That is certainly due to differences in the license to some extent, but if employers believe that they can get their employees to a quicker start when using LLVM, then this is bad for GCC. > >> > >> > It seems to me that with such a tool it's much easier > >> > to navigate from exp to the field, than having to scan through a much > >> > larger number of accessor functions / macros (GET_*). The former > >> > example starts at the source (exp) and yields/"builds" the result; the > >> > latter names some function and then says applies it to the source. Why > >> > is the former so much worse? To me, the former's structure is easier to > >> > see, and if I would have to put the spaghetti tag on something, then the > >> > latter. > >> > >> Sounds more like missed features or bugs in the tools you use. Heh, > >> after all our complaints that C++ will be harder to debug are deflected > >> to "that are gdb missing features / bugs". So - file bugs against Eclipse > >> (or whatever new and shiny programmers use these days), that it does > >> not work well with a codebase like GCC. > > > > Please don't dismiss this so easily. Of course this is just an example > > and nothing major, but I believe many people will use tab completion on > > the shell, for example, and code completion is really similar. On the > > shell, or with paths names, you start with typing something, then can > > navigate from this context you provided. That just works better when > > you say context->function instead of function(context). > > And I'm not a cognitive psychologist, but to me, seeing the context > > first when reading left-to-right is also slightly easier to read. > > Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z) > because operator precedence is visible. > > Similar for doit (a, b) compared to a.doit (b) (or b.doit (a) - what preference > is there for two inputs?). So you likely end up with a mix anyway. Yes. But mult, add, and the doit don't have a single context, they have two. On the other hand, consider two-input but single-context examples such as read(obj, property) vs. obj.read(property); which makes the context more easily visible? So, it's not about the number of inputs, it's whether there is a dominating context. You have that, for example, when starting navigating a graph from somewhere (eg, CFG), adding leafs to a tree node, getting or setting properties of an object, etc. I would guess that such operations are pretty common, more so than operations with more than one context. Also, I don't think anyone is arguing for a one-size-fits-all approach here. A mix isn't a problem really, as long as it easily reveals the structure of the program logic (e.g., stuff like contexts, or operator precedence as you mention). ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 13:13 ` Richard Guenther 2012-04-11 13:23 ` Gabriel Dos Reis 2012-04-11 14:19 ` Torvald Riegel @ 2012-04-11 17:24 ` Xinliang David Li 2012-04-11 18:17 ` Andrew Pinski 2012-04-11 18:26 ` Jonathan Wakely 2 siblings, 2 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 17:24 UTC (permalink / raw) To: Richard Guenther Cc: Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote: >> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: >>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote: >>> > Think about programmers new to GCC for a second, and about code >>> > completion tools. >>> >>> Honestly I care 1000 times more for existing GCC developers. Before >>> new programmers will have an easier time with GCC _existing_ GCC >>> developers will have to spend at least two GCC release cycles (that's >>> very optimistic) turning the GCC codebase upside-down. Every >>> existing GCC developer you lose on that way will slow down that >>> process and for every existing GCC developer you probably need more >>> that one "new" GCC developer starting. >>> >>> It's very easy for me to do the math and conclude that losing even _one_ >>> experienced existing GCC developer makes this whole transition-to-C++ >>> thing a non-starter. >> >> I agree that less work-force in the transition would be a problem. But >> is C++ (perceived to be) so bad that it would make people change their >> jobs? I mean, we're not talking about the experienced hobbyists here, >> or are we? > > Until some company puts money behind converting to C++ then yes, > it's the hobbyists (or the non-hobbyists in their spare time). > >> However, the concern you raised is only one part of the problem. The >> other is that, put in a simplified way, GCC is competing with LLVM about >> new and/or non-fulltime-compiler developers. For me, it looks like LLVM >> is more appealing to them, and I believe part of the reason for that is >> the codebase. >> Now, how many release cycles do we have until LLVM is basically good >> enough to be used as a distro compiler (e.g., until code quality and >> confidence in bug freedom is sufficiently similar)? If we haven't >> ensured that GCC is appealing by this time, why should new programmers >> then start considering GCC and not just go by default to LLVM? > > If you look at the existing developer base then the majority of it is paid. > And frankly while empolyers may listen to their employees, switching > from GCC to LLVM is not something they'd do based on a C++ vs. C > implementation language (but maybe based on availability of consulting > services or new employees or viability of using LLVM for weird architectures > or simply based on customer demand). Yes, GCC is still in some comfortable zones such as generated code quality, performance, etc, but the advantage and gap is quickly reducing (e.g, LLVM is the default compiler in Xcode) -- and other advantages in LLVM (will soon) outweigh its disadvantages. It has a very modern frontend Clang which is *very* attractive to application developers (better diagnostics, better IDE integration, easier to develop tools on, lean and mean etc); and believe it or not, their compiler developer base is also growing just for the perception it is more modern and it is easier to develop on (and words are spreading; there were also independent investigations on ease of development on some compiler features in gcc and LLVM from new developers and the result is in favor of LLVM). thanks, David > >>> >>> > It seems to me that with such a tool it's much easier >>> > to navigate from exp to the field, than having to scan through a much >>> > larger number of accessor functions / macros (GET_*). The former >>> > example starts at the source (exp) and yields/"builds" the result; the >>> > latter names some function and then says applies it to the source. Why >>> > is the former so much worse? To me, the former's structure is easier to >>> > see, and if I would have to put the spaghetti tag on something, then the >>> > latter. >>> >>> Sounds more like missed features or bugs in the tools you use. Heh, >>> after all our complaints that C++ will be harder to debug are deflected >>> to "that are gdb missing features / bugs". So - file bugs against Eclipse >>> (or whatever new and shiny programmers use these days), that it does >>> not work well with a codebase like GCC. >> >> Please don't dismiss this so easily. Of course this is just an example >> and nothing major, but I believe many people will use tab completion on >> the shell, for example, and code completion is really similar. On the >> shell, or with paths names, you start with typing something, then can >> navigate from this context you provided. That just works better when >> you say context->function instead of function(context). >> And I'm not a cognitive psychologist, but to me, seeing the context >> first when reading left-to-right is also slightly easier to read. > > Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z) > because operator precedence is visible. > > Similar for doit (a, b) compared to a.doit (b) (or b.doit (a) - what preference > is there for two inputs?). So you likely end up with a mix anyway. > > Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 17:24 ` Xinliang David Li @ 2012-04-11 18:17 ` Andrew Pinski 2012-04-11 20:02 ` Xinliang David Li 2012-04-12 5:08 ` Ian Lance Taylor 2012-04-11 18:26 ` Jonathan Wakely 1 sibling, 2 replies; 182+ messages in thread From: Andrew Pinski @ 2012-04-11 18:17 UTC (permalink / raw) To: Xinliang David Li Cc: Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 10:24 AM, Xinliang David Li <davidxl@google.com> wrote: > On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther > <richard.guenther@gmail.com> wrote: >> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote: >>> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: >>>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote: >>>> > Think about programmers new to GCC for a second, and about code >>>> > completion tools. >>>> >>>> Honestly I care 1000 times more for existing GCC developers. Before >>>> new programmers will have an easier time with GCC _existing_ GCC >>>> developers will have to spend at least two GCC release cycles (that's >>>> very optimistic) turning the GCC codebase upside-down. Every >>>> existing GCC developer you lose on that way will slow down that >>>> process and for every existing GCC developer you probably need more >>>> that one "new" GCC developer starting. >>>> >>>> It's very easy for me to do the math and conclude that losing even _one_ >>>> experienced existing GCC developer makes this whole transition-to-C++ >>>> thing a non-starter. >>> >>> I agree that less work-force in the transition would be a problem. But >>> is C++ (perceived to be) so bad that it would make people change their >>> jobs? I mean, we're not talking about the experienced hobbyists here, >>> or are we? >> >> Until some company puts money behind converting to C++ then yes, >> it's the hobbyists (or the non-hobbyists in their spare time). >> >>> However, the concern you raised is only one part of the problem. The >>> other is that, put in a simplified way, GCC is competing with LLVM about >>> new and/or non-fulltime-compiler developers. For me, it looks like LLVM >>> is more appealing to them, and I believe part of the reason for that is >>> the codebase. >>> Now, how many release cycles do we have until LLVM is basically good >>> enough to be used as a distro compiler (e.g., until code quality and >>> confidence in bug freedom is sufficiently similar)? If we haven't >>> ensured that GCC is appealing by this time, why should new programmers >>> then start considering GCC and not just go by default to LLVM? >> >> If you look at the existing developer base then the majority of it is paid. >> And frankly while empolyers may listen to their employees, switching >> from GCC to LLVM is not something they'd do based on a C++ vs. C >> implementation language (but maybe based on availability of consulting >> services or new employees or viability of using LLVM for weird architectures >> or simply based on customer demand). > > Yes, GCC is still in some comfortable zones such as generated code > quality, performance, etc, but the advantage and gap is quickly > reducing (e.g, LLVM is the default compiler in Xcode) -- and other > advantages in LLVM (will soon) outweigh its disadvantages. It has a > very modern frontend Clang which is *very* attractive to application > developers (better diagnostics, better IDE integration, easier to > develop tools on, lean and mean etc); and believe it or not, their > compiler developer base is also growing just for the perception it is > more modern and it is easier to develop on (and words are spreading; > there were also independent investigations on ease of development on > some compiler features in gcc and LLVM from new developers and the > result is in favor of LLVM). The main reason why LLVM is the default compiler in XCode is license rather any technical reason. And GCC usually has better diagnostic than clang except in those few areas which it does not (those some might say those areas are the most important ones). I have known people who does not want to deal with GCC because they are very anti GPL or GNU rather than GCC having a clean/modern interface. It is hard to win those guys over but those are the ones which are spreading in some cases FUD about GCC. -- Pinski ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 18:17 ` Andrew Pinski @ 2012-04-11 20:02 ` Xinliang David Li 2012-04-12 5:08 ` Ian Lance Taylor 1 sibling, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 20:02 UTC (permalink / raw) To: Andrew Pinski Cc: Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 11:17 AM, Andrew Pinski <pinskia@gmail.com> wrote: > On Wed, Apr 11, 2012 at 10:24 AM, Xinliang David Li <davidxl@google.com> wrote: >> On Wed, Apr 11, 2012 at 6:13 AM, Richard Guenther >> <richard.guenther@gmail.com> wrote: >>> On Wed, Apr 11, 2012 at 2:57 PM, Torvald Riegel <triegel@redhat.com> wrote: >>>> On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: >>>>> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote: >>>>> > Think about programmers new to GCC for a second, and about code >>>>> > completion tools. >>>>> >>>>> Honestly I care 1000 times more for existing GCC developers. Before >>>>> new programmers will have an easier time with GCC _existing_ GCC >>>>> developers will have to spend at least two GCC release cycles (that's >>>>> very optimistic) turning the GCC codebase upside-down. Every >>>>> existing GCC developer you lose on that way will slow down that >>>>> process and for every existing GCC developer you probably need more >>>>> that one "new" GCC developer starting. >>>>> >>>>> It's very easy for me to do the math and conclude that losing even _one_ >>>>> experienced existing GCC developer makes this whole transition-to-C++ >>>>> thing a non-starter. >>>> >>>> I agree that less work-force in the transition would be a problem. But >>>> is C++ (perceived to be) so bad that it would make people change their >>>> jobs? I mean, we're not talking about the experienced hobbyists here, >>>> or are we? >>> >>> Until some company puts money behind converting to C++ then yes, >>> it's the hobbyists (or the non-hobbyists in their spare time). >>> >>>> However, the concern you raised is only one part of the problem. The >>>> other is that, put in a simplified way, GCC is competing with LLVM about >>>> new and/or non-fulltime-compiler developers. For me, it looks like LLVM >>>> is more appealing to them, and I believe part of the reason for that is >>>> the codebase. >>>> Now, how many release cycles do we have until LLVM is basically good >>>> enough to be used as a distro compiler (e.g., until code quality and >>>> confidence in bug freedom is sufficiently similar)? If we haven't >>>> ensured that GCC is appealing by this time, why should new programmers >>>> then start considering GCC and not just go by default to LLVM? >>> >>> If you look at the existing developer base then the majority of it is paid. >>> And frankly while empolyers may listen to their employees, switching >>> from GCC to LLVM is not something they'd do based on a C++ vs. C >>> implementation language (but maybe based on availability of consulting >>> services or new employees or viability of using LLVM for weird architectures >>> or simply based on customer demand). >> >> Yes, GCC is still in some comfortable zones such as generated code >> quality, performance, etc, but the advantage and gap is quickly >> reducing (e.g, LLVM is the default compiler in Xcode) -- and other >> advantages in LLVM (will soon) outweigh its disadvantages. It has a >> very modern frontend Clang which is *very* attractive to application >> developers (better diagnostics, better IDE integration, easier to >> develop tools on, lean and mean etc); and believe it or not, their >> compiler developer base is also growing just for the perception it is >> more modern and it is easier to develop on (and words are spreading; >> there were also independent investigations on ease of development on >> some compiler features in gcc and LLVM from new developers and the >> result is in favor of LLVM). > > The main reason why LLVM is the default compiler in XCode is license > rather any technical reason. > And GCC usually has better diagnostic than clang except in those few > areas which it does not (those some might say those areas are the most > important ones). > > I have known people who does not want to deal with GCC because they > are very anti GPL or GNU rather than GCC having a clean/modern > interface. > > It is hard to win those guys over but those are the ones which are > spreading in some cases FUD about GCC. > Possibly true -- it might be a good idea to collect more data to backup any claims here. David > -- Pinski ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 18:17 ` Andrew Pinski 2012-04-11 20:02 ` Xinliang David Li @ 2012-04-12 5:08 ` Ian Lance Taylor 2012-04-12 6:12 ` Miles Bader 1 sibling, 1 reply; 182+ messages in thread From: Ian Lance Taylor @ 2012-04-12 5:08 UTC (permalink / raw) To: Andrew Pinski Cc: Xinliang David Li, Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc Andrew Pinski <pinskia@gmail.com> writes: > The main reason why LLVM is the default compiler in XCode is license > rather any technical reason. Yes. > And GCC usually has better diagnostic than clang except in those few > areas which it does not (those some might say those areas are the most > important ones). No. clang's diagnostics for C++ are much much better than GCC's. Obviously GCC's can improve, but today clang's are much better. Ian ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-12 5:08 ` Ian Lance Taylor @ 2012-04-12 6:12 ` Miles Bader 2012-04-12 6:22 ` James Dennett 0 siblings, 1 reply; 182+ messages in thread From: Miles Bader @ 2012-04-12 6:12 UTC (permalink / raw) To: Ian Lance Taylor Cc: Andrew Pinski, Xinliang David Li, Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc Ian Lance Taylor <iant@google.com> writes: >> And GCC usually has better diagnostic than clang except in those few >> areas which it does not (those some might say those areas are the most >> important ones). > > No. clang's diagnostics for C++ are much much better than GCC's. > Obviously GCC's can improve, but today clang's are much better. Meh. Clang's diagnostics are often pretty good, and it's rightly lauded for that, but the "OMG clang totally murders gcc for diagnostics!" meme (which seems to be staple of clang's unfortunately large fanboi contingent) is an exaggeration. Clang's diagnostics are not _that_ good, gcc's are [currently] not that bad, and the situations where the difference is the most noticeable tend to be obscure. (remember: Only Henry Spencer can say "No." and really get away with it...) -miles -- Non-combatant, n. A dead Quaker. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-12 6:12 ` Miles Bader @ 2012-04-12 6:22 ` James Dennett 0 siblings, 0 replies; 182+ messages in thread From: James Dennett @ 2012-04-12 6:22 UTC (permalink / raw) To: Miles Bader Cc: Ian Lance Taylor, Andrew Pinski, Xinliang David Li, Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 11:11 PM, Miles Bader <miles@gnu.org> wrote: > Ian Lance Taylor <iant@google.com> writes: >>> And GCC usually has better diagnostic than clang except in those few >>> areas which it does not (those some might say those areas are the most >>> important ones). >> >> No. clang's diagnostics for C++ are much much better than GCC's. >> Obviously GCC's can improve, but today clang's are much better. > > Meh. Clang's diagnostics are often pretty good, and it's rightly lauded > for that, but the "OMG clang totally murders gcc for diagnostics!" meme > (which seems to be staple of clang's unfortunately large fanboi > contingent) is an exaggeration. Yes, the most extreme advocates (of anything) tend to get lost in a land of exaggeration. > Clang's diagnostics are not _that_ good, I'd agree there. > gcc's are [currently] not that bad, But for common cases (and a lot of less common ones) they're nowhere near as good as Clang's... > and the situations where the > difference is the most noticeable tend to be obscure. Here, based on experience, I disagree. I often have non-experts mention to me just how surprisingly clear/useful they've found Clang's error messages (with cause), and that essentially never happened for gcc's error messages. There are many common cases where Clang correctly identifies the user's mistake, and gcc reports something that is formally correct but much harder to map back to what the user did wrong. I don't disagree that gcc's diagnostics have greatly improved, and seem to continue to do so, but they're still a long way behind. Which isn't to say that Clang doesn't have issues -- some fraction of the time I find Clang's diagnostics to be pretty awful, and I'm so used to deciphering gcc's messages that I often don't notice how far removed they are from the underlying problem. However, this gets dangerously close to thread-jacking, and I don't want to digress too far into GCC vs Clang comparisons. The two are different and have somewhat different goals, and IMO competition is good for the community overall. -- James ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 17:24 ` Xinliang David Li 2012-04-11 18:17 ` Andrew Pinski @ 2012-04-11 18:26 ` Jonathan Wakely 2012-04-11 18:41 ` Pedro Alves 2012-04-11 20:00 ` Xinliang David Li 1 sibling, 2 replies; 182+ messages in thread From: Jonathan Wakely @ 2012-04-11 18:26 UTC (permalink / raw) To: Xinliang David Li Cc: Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 11 April 2012 18:24, Xinliang David Li wrote: > > Yes, GCC is still in some comfortable zones such as generated code > quality, performance, etc, but the advantage and gap is quickly > reducing (e.g, LLVM is the default compiler in Xcode) -- and other > advantages in LLVM (will soon) outweigh its disadvantages. It has a > very modern frontend Clang which is *very* attractive to application > developers (better diagnostics, better IDE integration, easier to ... GCC's diagnostics have got a lot better recently. The http://clang.llvm.org/diagnostics.html page compares clang's diagnostics to GCC 4.2, which was outdated long before that page was written. It doesn't help GCC's cause when people keep repeating that outdated info :-) ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 18:26 ` Jonathan Wakely @ 2012-04-11 18:41 ` Pedro Alves 2012-04-11 20:00 ` Xinliang David Li 1 sibling, 0 replies; 182+ messages in thread From: Pedro Alves @ 2012-04-11 18:41 UTC (permalink / raw) To: Jonathan Wakely Cc: Xinliang David Li, Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 04/11/2012 07:26 PM, Jonathan Wakely wrote: > GCC's diagnostics have got a lot better recently. > > The http://clang.llvm.org/diagnostics.html page compares clang's > diagnostics to GCC 4.2, which was outdated long before that page was > written. > > It doesn't help GCC's cause when people keep repeating that outdated info :-) Spelling out the obvious, IWBVN if someone from the gcc camp did a similar comparison using a current gcc. Is there such a page somewhere? -- Pedro Alves ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 18:26 ` Jonathan Wakely 2012-04-11 18:41 ` Pedro Alves @ 2012-04-11 20:00 ` Xinliang David Li 2012-04-11 20:05 ` Jonathan Wakely 1 sibling, 1 reply; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 20:00 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > On 11 April 2012 18:24, Xinliang David Li wrote: >> >> Yes, GCC is still in some comfortable zones such as generated code >> quality, performance, etc, but the advantage and gap is quickly >> reducing (e.g, LLVM is the default compiler in Xcode) -- and other >> advantages in LLVM (will soon) outweigh its disadvantages. It has a >> very modern frontend Clang which is *very* attractive to application >> developers (better diagnostics, better IDE integration, easier to > ... > > GCC's diagnostics have got a lot better recently. > Proof? A similar page from gcc would be more helpful here. > The http://clang.llvm.org/diagnostics.html page compares clang's > diagnostics to GCC 4.2, which was outdated long before that page was > written. > > It doesn't help GCC's cause when people keep repeating that outdated info :-) Well -- because there is no up-to-date information for people to look at :(. David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 20:00 ` Xinliang David Li @ 2012-04-11 20:05 ` Jonathan Wakely 2012-04-12 5:10 ` Ian Lance Taylor 0 siblings, 1 reply; 182+ messages in thread From: Jonathan Wakely @ 2012-04-11 20:05 UTC (permalink / raw) To: Xinliang David Li Cc: Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 11 April 2012 21:00, Xinliang David Li <davidxl@google.com> wrote: > On Wed, Apr 11, 2012 at 11:26 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: >> On 11 April 2012 18:24, Xinliang David Li wrote: >>> >>> Yes, GCC is still in some comfortable zones such as generated code >>> quality, performance, etc, but the advantage and gap is quickly >>> reducing (e.g, LLVM is the default compiler in Xcode) -- and other >>> advantages in LLVM (will soon) outweigh its disadvantages. It has a >>> very modern frontend Clang which is *very* attractive to application >>> developers (better diagnostics, better IDE integration, easier to >> ... >> >> GCC's diagnostics have got a lot better recently. >> > > Proof? A similar page from gcc would be more helpful here. It's all in bugzilla. Look for Nathan Froyd's checkins e.g. regarding missing semi-colons after class declarations and reasons for overload resolution failure and template argument deduction failures. And Manu's work on many diagnostic issues includes the brand new caret diagnostics. I don't need proof, I see the benefits every day. Those who need convincing should feel free to do the comparisons themselves :-) I can provide testcases for which G++ produces far superior results to clang++. >> The http://clang.llvm.org/diagnostics.html page compares clang's >> diagnostics to GCC 4.2, which was outdated long before that page was >> written. >> >> It doesn't help GCC's cause when people keep repeating that outdated info :-) > > Well -- because there is no up-to-date information for people to look at :(. I get my views on their relative merits from actually using GCC and clang, not from out of date webpages. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 20:05 ` Jonathan Wakely @ 2012-04-12 5:10 ` Ian Lance Taylor 0 siblings, 0 replies; 182+ messages in thread From: Ian Lance Taylor @ 2012-04-12 5:10 UTC (permalink / raw) To: Jonathan Wakely Cc: Xinliang David Li, Richard Guenther, Torvald Riegel, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc Jonathan Wakely <jwakely.gcc@gmail.com> writes: > I get my views on their relative merits from actually using GCC and > clang, not from out of date webpages. Me too, and I think clang's are better. Simply having caret diagnostics and good suggestions are quite important for people who are not C++ experts. Ian ^ permalink raw reply [flat|nested] 182+ messages in thread
[parent not found: <12130397.ZsTVnyYbKR@pawels>]
* Re: Switching to C++ by default in 4.8 [not found] ` <12130397.ZsTVnyYbKR@pawels> @ 2012-04-11 13:14 ` Richard Guenther 0 siblings, 0 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-11 13:14 UTC (permalink / raw) To: Paweł Sikora Cc: gcc, Torvald Riegel, Michael Matz, Xinliang David Li, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo 2012/4/11 Paweł Sikora <pluto@agmk.net>: > On Wednesday 11 of April 2012 14:57:53 Torvald Riegel wrote: > > > >> Now, how many release cycles do we have until LLVM is basically good > >> enough to be used as a distro compiler > > > > freebsd-9 switches to clang/llvm as a distro compiler. > > some info @ http://wiki.freebsd.org/BuildingFreeBSDWithClang Only because we are so evil to not maintain their GPL v2 GCC 4.2.2 codebase anymore :P Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:58 ` Torvald Riegel 2012-04-11 13:13 ` Richard Guenther [not found] ` <12130397.ZsTVnyYbKR@pawels> @ 2012-04-11 13:24 ` Bernd Schmidt 2012-04-11 17:31 ` Xinliang David Li 2012-04-13 23:45 ` Dave Korn 2012-04-11 14:41 ` Jonathan Wakely ` (3 subsequent siblings) 6 siblings, 2 replies; 182+ messages in thread From: Bernd Schmidt @ 2012-04-11 13:24 UTC (permalink / raw) To: Torvald Riegel Cc: Richard Guenther, Michael Matz, Xinliang David Li, Jakub Jelinek, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 04/11/2012 02:57 PM, Torvald Riegel wrote: > However, the concern you raised is only one part of the problem. The > other is that, put in a simplified way, GCC is competing with LLVM about > new and/or non-fulltime-compiler developers. For me, it looks like LLVM > is more appealing to them, and I believe part of the reason for that is > the codebase. There seem to be other opinions as well, some voiced in this thread, which just supports my argument that you can't do it right for everyone. Part of the reason LLVM is appealing may just be advertising, which we don't do at all, perhaps due to the deep-seated inferiority complex we have about gcc. > Now, how many release cycles do we have until LLVM is basically good > enough to be used as a distro compiler (e.g., until code quality and > confidence in bug freedom is sufficiently similar)? If we haven't > ensured that GCC is appealing by this time, why should new programmers > then start considering GCC and not just go by default to LLVM? Maybe we should concentrate on our own strengths. Improve the optimizers, support more targets well, fully implement language standards, etc. Spending developer time on something fruitless like a language switch has an opportunity cost, it just gives competing projects more time to catch up in areas that matter for users. Bernd ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 13:24 ` Bernd Schmidt @ 2012-04-11 17:31 ` Xinliang David Li 2012-04-11 18:37 ` Basile Starynkevitch 2012-04-13 23:45 ` Dave Korn 1 sibling, 1 reply; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 17:31 UTC (permalink / raw) To: Bernd Schmidt Cc: Torvald Riegel, Richard Guenther, Michael Matz, Jakub Jelinek, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 6:21 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 04/11/2012 02:57 PM, Torvald Riegel wrote: >> However, the concern you raised is only one part of the problem. The >> other is that, put in a simplified way, GCC is competing with LLVM about >> new and/or non-fulltime-compiler developers. For me, it looks like LLVM >> is more appealing to them, and I believe part of the reason for that is >> the codebase. > > There seem to be other opinions as well, some voiced in this thread, > which just supports my argument that you can't do it right for everyone. > Part of the reason LLVM is appealing may just be advertising, which we > don't do at all, perhaps due to the deep-seated inferiority complex we > have about gcc. yes -- GCC is not considered old and not 'cool' -- so it is hard to advertise. One criteria to see GCC's future popularity is how widely it is adopted by academia .. > >> Now, how many release cycles do we have until LLVM is basically good >> enough to be used as a distro compiler (e.g., until code quality and >> confidence in bug freedom is sufficiently similar)? If we haven't >> ensured that GCC is appealing by this time, why should new programmers >> then start considering GCC and not just go by default to LLVM? > > Maybe we should concentrate on our own strengths. Improve the > optimizers, support more targets well, fully implement language > standards, etc. Spending developer time on something fruitless like a > language switch has an opportunity cost, it just gives competing > projects more time to catch up in areas that matter for users. but LLVM is not standing still either .. David > > > Bernd ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 17:31 ` Xinliang David Li @ 2012-04-11 18:37 ` Basile Starynkevitch 2012-04-11 18:52 ` Gabriel Dos Reis ` (2 more replies) 0 siblings, 3 replies; 182+ messages in thread From: Basile Starynkevitch @ 2012-04-11 18:37 UTC (permalink / raw) To: Xinliang David Li; +Cc: gcc On Wed, 11 Apr 2012 10:30:36 -0700 Xinliang David Li <davidxl@google.com> wrote: [..] > > yes -- GCC is not considered old and not 'cool' -- so it is hard to > advertise. One criteria to see GCC's future popularity is how widely > it is adopted by academia .. Do you mean used by academia (including teaching programming with students using GCC), or do you mean that academia is teaching the internals of GCC, and e.g. have lots of e.g. PhD students & professors doing their research using and *improving* GCC. My feeling is that the plugin ability of GCC should help academia to work more on (that is, "inside") GCC, to only to use GCC. (and I am not very very optimistic, in particular because the internal APIs of GCC are not very well documented, not very well agreed upon...). Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 18:37 ` Basile Starynkevitch @ 2012-04-11 18:52 ` Gabriel Dos Reis 2012-04-11 20:14 ` Xinliang David Li 2012-04-12 15:51 ` Ludovic Courtès 2 siblings, 0 replies; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-11 18:52 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: Xinliang David Li, gcc On Wed, Apr 11, 2012 at 1:37 PM, Basile Starynkevitch <basile@starynkevitch.net> wrote: > On Wed, 11 Apr 2012 10:30:36 -0700 > Xinliang David Li <davidxl@google.com> wrote: > [..] >> >> yes -- GCC is not considered old and not 'cool' -- so it is hard to >> advertise. One criteria to see GCC's future popularity is how widely >> it is adopted by academia .. > > > Do you mean used by academia (including teaching programming with students using GCC), or > do you mean that academia is teaching the internals of GCC, and e.g. have lots of e.g. > PhD students & professors doing their research using and *improving* GCC. I don't see how acceptable plugins for GCC would make my students' life easy for the projects they are currently working on. But, I can see other projects with less invasive structures -- but then there are many alternative infrastructures out there that would make such projects just as easy (starting with eclipse or clang) for the kind of things academia is usually excited about. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 18:37 ` Basile Starynkevitch 2012-04-11 18:52 ` Gabriel Dos Reis @ 2012-04-11 20:14 ` Xinliang David Li 2012-04-12 15:51 ` Ludovic Courtès 2 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 20:14 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc On Wed, Apr 11, 2012 at 11:37 AM, Basile Starynkevitch <basile@starynkevitch.net> wrote: > On Wed, 11 Apr 2012 10:30:36 -0700 > Xinliang David Li <davidxl@google.com> wrote: > [..] >> >> yes -- GCC is not considered old and not 'cool' -- so it is hard to >> advertise. One criteria to see GCC's future popularity is how widely >> it is adopted by academia .. > > > Do you mean used by academia (including teaching programming with students using GCC), or > do you mean that academia is teaching the internals of GCC, and e.g. have lots of e.g. > PhD students & professors doing their research using and *improving* GCC. I mean to use GCC infrastructure to do research such as program analysis and develop very advanced optimization techniques. > > My feeling is that the plugin ability of GCC should help academia to work more on (that > is, "inside") GCC, to only to use GCC. Plugins can be useful for function level work. For IPA, plugins probably won't be useful. For instance, if someone wants to develop very advanced CS/FS sensitive alias analysis in GCC and demonstrate performance, the aliaser should provide good update APIs to allow the new analysis results to be usable by backend components (transparently) without worrying about how the data can be used. > > (and I am not very very optimistic, in particular because the internal APIs of GCC are > not very well documented, not very well agreed upon...). > And old plugins can get out of sync with core IRs easily due to lack of good data isolation/hiding. If gcc has a well defined streaming format and standard ir reader/writer, it will make tool developers very happy. David > Cheers. > > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 18:37 ` Basile Starynkevitch 2012-04-11 18:52 ` Gabriel Dos Reis 2012-04-11 20:14 ` Xinliang David Li @ 2012-04-12 15:51 ` Ludovic Courtès 2 siblings, 0 replies; 182+ messages in thread From: Ludovic Courtès @ 2012-04-12 15:51 UTC (permalink / raw) To: gcc Hi, Basile Starynkevitch <basile@starynkevitch.net> skribis: > My feeling is that the plugin ability of GCC should help academia to work more on (that > is, "inside") GCC, to only to use GCC. Yes, except that, on one hand, they have a library stack with stable APIs, and on the other, an otherwise quite stable API that GCC hackers say âshould not be usedâ by plug-ins. This, together with LLVM being in fashion, tends to push âacademiaâ away from GCC, I think. Thanks, Ludoâ. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 13:24 ` Bernd Schmidt 2012-04-11 17:31 ` Xinliang David Li @ 2012-04-13 23:45 ` Dave Korn 1 sibling, 0 replies; 182+ messages in thread From: Dave Korn @ 2012-04-13 23:45 UTC (permalink / raw) To: Bernd Schmidt Cc: Torvald Riegel, Richard Guenther, Michael Matz, Xinliang David Li, Jakub Jelinek, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 11/04/2012 14:21, Bernd Schmidt wrote: > On 04/11/2012 02:57 PM, Torvald Riegel wrote: >> However, the concern you raised is only one part of the problem. The >> other is that, put in a simplified way, GCC is competing with LLVM about >> new and/or non-fulltime-compiler developers. For me, it looks like LLVM >> is more appealing to them, and I believe part of the reason for that is >> the codebase. > > There seem to be other opinions as well, some voiced in this thread, > which just supports my argument that you can't do it right for everyone. > Part of the reason LLVM is appealing may just be advertising, which we > don't do at all, perhaps due to the deep-seated inferiority complex we > have about gcc. Inferiority complex? I think this thread suggests (and perhaps the -Wall thread too) that we're more in danger of complacently resting on our laurels. We have huge inertia, but just because we've always been the big name in embedded toolkits doesn't mean we always will be. cheers, DaveK ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:58 ` Torvald Riegel ` (2 preceding siblings ...) 2012-04-11 13:24 ` Bernd Schmidt @ 2012-04-11 14:41 ` Jonathan Wakely 2012-04-11 17:13 ` Xinliang David Li ` (2 subsequent siblings) 6 siblings, 0 replies; 182+ messages in thread From: Jonathan Wakely @ 2012-04-11 14:41 UTC (permalink / raw) To: Torvald Riegel Cc: Richard Guenther, Michael Matz, Xinliang David Li, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 11 April 2012 13:57, Torvald Riegel wrote: > Now, how many release cycles do we have until LLVM is basically good > enough to be used as a distro compiler (e.g., until code quality and > confidence in bug freedom is sufficiently similar)? If we haven't > ensured that GCC is appealing by this time, why should new programmers > then start considering GCC and not just go by default to LLVM? Well it would need a C++ standard library that works on GNU/Linux first, unless distros want to rely on a compiler+stdlib combination that isn't supported by either the compiler vendor or the stdlib vendor. Not many distros have their own libstdc++ developers and although I think it's good that libstdc++ works with clang, supporting it is not high on my priority list. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:58 ` Torvald Riegel ` (3 preceding siblings ...) 2012-04-11 14:41 ` Jonathan Wakely @ 2012-04-11 17:13 ` Xinliang David Li 2012-04-11 19:30 ` Tobias Burnus 2012-04-13 23:37 ` Dave Korn 6 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 17:13 UTC (permalink / raw) To: Torvald Riegel Cc: Richard Guenther, Michael Matz, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 5:57 AM, Torvald Riegel <triegel@redhat.com> wrote: > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: >> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <triegel@redhat.com> wrote: >> > Think about programmers new to GCC for a second, and about code >> > completion tools. >> >> Honestly I care 1000 times more for existing GCC developers. Before >> new programmers will have an easier time with GCC _existing_ GCC >> developers will have to spend at least two GCC release cycles (that's >> very optimistic) turning the GCC codebase upside-down. Every >> existing GCC developer you lose on that way will slow down that >> process and for every existing GCC developer you probably need more >> that one "new" GCC developer starting. >> >> It's very easy for me to do the math and conclude that losing even _one_ >> experienced existing GCC developer makes this whole transition-to-C++ >> thing a non-starter. > > I agree that less work-force in the transition would be a problem. But > is C++ (perceived to be) so bad that it would make people change their > jobs? I mean, we're not talking about the experienced hobbyists here, > or are we? > > However, the concern you raised is only one part of the problem. The > other is that, put in a simplified way, GCC is competing with LLVM about > new and/or non-fulltime-compiler developers. For me, it looks like LLVM > is more appealing to them, and I believe part of the reason for that is > the codebase. > Now, how many release cycles do we have until LLVM is basically good > enough to be used as a distro compiler (e.g., until code quality and > confidence in bug freedom is sufficiently similar)? If we haven't > ensured that GCC is appealing by this time, why should new programmers > then start considering GCC and not just go by default to LLVM? Yes -- this should be the main motivation factor for GCC to make major changes or even leapfrog -- LLVM is also more than 10 years old. David > >> >> > It seems to me that with such a tool it's much easier >> > to navigate from exp to the field, than having to scan through a much >> > larger number of accessor functions / macros (GET_*). The former >> > example starts at the source (exp) and yields/"builds" the result; the >> > latter names some function and then says applies it to the source. Why >> > is the former so much worse? To me, the former's structure is easier to >> > see, and if I would have to put the spaghetti tag on something, then the >> > latter. >> >> Sounds more like missed features or bugs in the tools you use. Heh, >> after all our complaints that C++ will be harder to debug are deflected >> to "that are gdb missing features / bugs". So - file bugs against Eclipse >> (or whatever new and shiny programmers use these days), that it does >> not work well with a codebase like GCC. > > Please don't dismiss this so easily. Of course this is just an example > and nothing major, but I believe many people will use tab completion on > the shell, for example, and code completion is really similar. On the > shell, or with paths names, you start with typing something, then can > navigate from this context you provided. That just works better when > you say context->function instead of function(context). > And I'm not a cognitive psychologist, but to me, seeing the context > first when reading left-to-right is also slightly easier to read. > ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:58 ` Torvald Riegel ` (4 preceding siblings ...) 2012-04-11 17:13 ` Xinliang David Li @ 2012-04-11 19:30 ` Tobias Burnus 2012-04-11 20:44 ` Torvald Riegel 2012-04-13 23:48 ` Dave Korn 2012-04-13 23:37 ` Dave Korn 6 siblings, 2 replies; 182+ messages in thread From: Tobias Burnus @ 2012-04-11 19:30 UTC (permalink / raw) To: Torvald Riegel; +Cc: gcc Torvald Riegel wrote: > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: >> > Honestly I care 1000 times more for existing GCC developers. Before >> > new programmers will have an easier time with GCC_existing_ GCC >> > developers will have to spend at least two GCC release cycles (that's >> > very optimistic) turning the GCC codebase upside-down. Every >> > existing GCC developer you lose on that way will slow down that >> > process and for every existing GCC developer you probably need more >> > that one "new" GCC developer starting. >> > >> > It's very easy for me to do the math and conclude that losing even_one_ >> > experienced existing GCC developer makes this whole transition-to-C++ >> > thing a non-starter. > I agree that less work-force in the transition would be a problem. But > is C++ (perceived to be) so bad that it would make people change their > jobs? I mean, we're not talking about the experienced hobbyists here, > or are we? I hope we are! At least GCC's Fortran front end is mostly developed by experienced hobbyist - and I know some who do not want to learn C++ to be able to continue with the project. However, I have some confidence that the changes will be such that no developer will give up. In any case, the gfortran front end cannot really afford to loose developers, given that it is a hobbyist* project and given that attracting new developers is difficult. Tobias * In terms of the development; I assume that those who use it for embedded systems or on the top500 supercomputers, at aircraft manufactures, weather services or for academic research get paid. ;-) ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 19:30 ` Tobias Burnus @ 2012-04-11 20:44 ` Torvald Riegel 2012-04-13 23:48 ` Dave Korn 1 sibling, 0 replies; 182+ messages in thread From: Torvald Riegel @ 2012-04-11 20:44 UTC (permalink / raw) To: Tobias Burnus; +Cc: gcc On Wed, 2012-04-11 at 21:30 +0200, Tobias Burnus wrote: > Torvald Riegel wrote: > > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: > >> > Honestly I care 1000 times more for existing GCC developers. Before > >> > new programmers will have an easier time with GCC_existing_ GCC > >> > developers will have to spend at least two GCC release cycles (that's > >> > very optimistic) turning the GCC codebase upside-down. Every > >> > existing GCC developer you lose on that way will slow down that > >> > process and for every existing GCC developer you probably need more > >> > that one "new" GCC developer starting. > >> > > >> > It's very easy for me to do the math and conclude that losing even_one_ > >> > experienced existing GCC developer makes this whole transition-to-C++ > >> > thing a non-starter. > > I agree that less work-force in the transition would be a problem. But > > is C++ (perceived to be) so bad that it would make people change their > > jobs? I mean, we're not talking about the experienced hobbyists here, > > or are we? > > I hope we are! At least GCC's Fortran front end is mostly developed by > experienced hobbyist - and I know some who do not want to learn C++ to > be able to continue with the project. However, I have some confidence > that the changes will be such that no developer will give up. To avoid any misunderstandings, I'd like to stress that my comment was explicitly a reply to Richard's comment about paid developers. I do think that non-full-time developers are important for the project, that's why I raised the point of attracting new developers in the first place. I guess it doesn't really make a difference for our discussion whether those developers are hobbyist, paid to work on something minor or some project, or just experimenting with new stuff (e.g., researchers); what they likely have in common is that they need to get meaningful stuff done fast but don't have the time to master every corner of GCC first. In contrast, if you're working on something full-time for several years, then yes, you'll know everything about it, including all the weird bits, workarounds, and idioms; any change then has a cost. But if the amount of this required information is large (e.g., the code base is complicated, full of unexpected surprises, or just cannot be worked on in a localized fashion), then non-full-time developers have a hard time working with GCC; every time they switch from their other projects / day job / ... to working on GCC, the context switch cost is huge. Same applies when starting to work on GCC for the first time. Regarding learning C++, I wouldn't worry much about this. If you look at the list that Lawrence Crowl sent, for example, lots of the example benefits in there are pretty transparent if you just use them, and easy to learn. Perhaps some slightly more advanced C++ knowledge is required when adding core data structures, but these will follow common patterns too I suppose. Torvald ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 19:30 ` Tobias Burnus 2012-04-11 20:44 ` Torvald Riegel @ 2012-04-13 23:48 ` Dave Korn 1 sibling, 0 replies; 182+ messages in thread From: Dave Korn @ 2012-04-13 23:48 UTC (permalink / raw) To: Tobias Burnus; +Cc: Torvald Riegel, gcc On 11/04/2012 20:30, Tobias Burnus wrote: > In any case, the gfortran front end cannot really afford to loose > developers, given that it is a hobbyist* project and given that > attracting new developers is difficult. > > Tobias > > * In terms of the development; I assume that those who use it for > embedded systems or on the top500 supercomputers, at aircraft > manufactures, weather services or for academic research get paid. ;-) ;-) Maybe you could work together to twist some arms in management? cheers, DaveK ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:58 ` Torvald Riegel ` (5 preceding siblings ...) 2012-04-11 19:30 ` Tobias Burnus @ 2012-04-13 23:37 ` Dave Korn 6 siblings, 0 replies; 182+ messages in thread From: Dave Korn @ 2012-04-13 23:37 UTC (permalink / raw) To: Torvald Riegel Cc: Richard Guenther, Michael Matz, Xinliang David Li, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 11/04/2012 13:57, Torvald Riegel wrote: > Please don't dismiss this so easily. Of course this is just an example > and nothing major, but I believe many people will use tab completion on > the shell, for example, and code completion is really similar. On the > shell, or with paths names, you start with typing something, then can > navigate from this context you provided. That just works better when > you say context->function instead of function(context). Say, didn't someone submit a patch at some point to provide a completion-mode for GCC invoked from the command-line? And didn't we (the list) suggest that that would make a lot of sense when combined with the incremental/gccserver branch? Did anything ever happen about that? cheers, DaveK ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:24 ` Michael Matz 2012-04-10 17:08 ` Xinliang David Li 2012-04-10 17:29 ` Torvald Riegel @ 2012-04-10 17:48 ` DJ Delorie 2012-04-10 19:21 ` Dave Korn 3 siblings, 0 replies; 182+ messages in thread From: DJ Delorie @ 2012-04-10 17:48 UTC (permalink / raw) To: gcc Michael Matz <matz@suse.de> writes: > syntactic noise without any whitespace. Quite frankly, how anyone could > ever say that > > exp->as_component_ref().get_field() > > is easier to read/write/use than > > GET_FIELD_DECL (exp) C vs C++ is not the same argument as style A vs style B. Your argument could just as easily been this way: > syntactic noise without any whitespace. Quite frankly, how anyone could > ever say that > > exp.get_field_decl() > > is easier to read/write/use than > > GET_DECL (GET_FIELD (AS_COMPONENT (exp))) The choice of language does not force you to choose a style, those are independent choices. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:24 ` Michael Matz ` (2 preceding siblings ...) 2012-04-10 17:48 ` DJ Delorie @ 2012-04-10 19:21 ` Dave Korn 3 siblings, 0 replies; 182+ messages in thread From: Dave Korn @ 2012-04-10 19:21 UTC (permalink / raw) To: Michael Matz Cc: Xinliang David Li, Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 10/04/2012 17:24, Michael Matz wrote: > Hi, > > On Tue, 10 Apr 2012, Xinliang David Li wrote: > >>>>> exp->as_component_ref().get_field() .. > >>> Actually it's not questionable. The above stuff is _horrible_. >> Specifics please. It is _horrible_ because you are more used to the >> existing way and the new style does not match your taste or they are >> very hard to understand and use? > > Your style (I wouldn't call it The New Style) is visually distracting, and > therefore harder to understand and use, longer to write and full of > syntactic noise without any whitespace. Quite frankly, how anyone could > ever say that > > exp->as_component_ref().get_field() > > is easier to read/write/use than > > GET_FIELD_DECL (exp) > > (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without > all-caps, is completely beyond me. I pretty much hope that we never see > the ugliness of the first way in GCCs code base. Even in C++ it's > possible to write non-spaghetti code. So isn't #define GET_FIELD_DECL(exp) ((exp)->as_component_ref().get_field()) the simple solution to that one? cheers, DaveK ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 8:46 ` Jakub Jelinek 2012-04-10 12:26 ` Michael Matz @ 2012-04-10 16:23 ` Xinliang David Li 2012-04-10 16:39 ` Jakub Jelinek 2012-04-10 16:42 ` Paweł Sikora ` (3 subsequent siblings) 5 siblings, 1 reply; 182+ messages in thread From: Xinliang David Li @ 2012-04-10 16:23 UTC (permalink / raw) To: Jakub Jelinek Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: >> Class hierarchy is one such feature that is useful. Assuming we have >> two hierarchies for gcc: one for values rooted at ValExp, and one for >> gimple stmts rooted at GimpInst. >> >> 1) For IR browsing, >> *) all the macro accessors can be eliminated -- a big plus for debugging; > > Not that clear, if all the macros are replaced by tons of inline functions, > the debugging experience can be actually significantly worse. Already some the > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH > macro are extremely annoying from debugging POV. What is the root cause of the annoyance? Mixing macros and inline functions does not sound good, but using deeply nested macros do not seem to help the debugging situation either. > >> *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> >> e.g. >> exp->as_component_ref().get_field() .. >> exp->as_mem_access().get_base() ... >> exp->as_mem_acesss().get_address() --> produces the >> address expression for memory access >> exp->as_mem_access().get_alias_handle () >> >> gimple_inst->serialize (&fixup_list) --> a virtual >> function overriden by actual instruction types that knows its byte >> code format. > > That silently assumes we want to change basic GIMPLE/tree data structures > to virtual classes, which is a significant change that has a significant > cost as well. E.g. all such changed data structures grow by a virtual > pointer field. Those data structures are heavily optimized for memory > footprint. Not really -- not having flat interfaces as we have today does not mean virtual functions have to be used -- this is just implementation detail. > Not to mention it is very questionable if the above stuff is more readable > than what we currently have. The above is just quickly cooked up examples. A carefully designed C++ based API can be self documenting and make the client code very readable. It is hard to believe that there is no room for improvement in GCC. thanks, David > > Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:23 ` Xinliang David Li @ 2012-04-10 16:39 ` Jakub Jelinek 2012-04-10 16:43 ` Gabriel Dos Reis ` (3 more replies) 0 siblings, 4 replies; 182+ messages in thread From: Jakub Jelinek @ 2012-04-10 16:39 UTC (permalink / raw) To: Xinliang David Li Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote: > On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek <jakub@redhat.com> wrote: > > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: > >> Class hierarchy is one such feature that is useful. Assuming we have > >> two hierarchies for gcc: one for values rooted at ValExp, and one for > >> gimple stmts rooted at GimpInst. > >> > >> 1) For IR browsing, > >> Â Â *) all the macro accessors can be eliminated -- a big plus for debugging; > > > > Not that clear, if all the macros are replaced by tons of inline functions, > > the debugging experience can be actually significantly worse. Â Already some the > > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH > > macro are extremely annoying from debugging POV. > > What is the root cause of the annoyance? Mixing macros and inline > functions does not sound good, but using deeply nested macros do not > seem to help the debugging situation either. That when stepping through code in the debugger you keep enterring/exiting these one liner inlines, most of them really should be at least by default considered just as normal statements (e.g. glibc heavily uses artificial attribute for those, still gdb doesn't hide those by default). > > Not to mention it is very questionable if the above stuff is more readable > > than what we currently have. > > The above is just quickly cooked up examples. A carefully designed C++ > based API can be self documenting and make the client code very > readable. It is hard to believe that there is no room for improvement > in GCC. Do you have examples? E.g. I haven't touched gold, because, while it is a new C++ codebase, looks completely unreadable to me, similarly libdw C++ stuff. A carefully designed C based API can be self documenting and make the code very readable as well, often more so. Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:39 ` Jakub Jelinek @ 2012-04-10 16:43 ` Gabriel Dos Reis 2012-04-10 16:47 ` Diego Novillo 2012-04-10 17:37 ` Torvald Riegel ` (2 subsequent siblings) 3 siblings, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-10 16:43 UTC (permalink / raw) To: Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 11:39 AM, Jakub Jelinek <jakub@redhat.com> wrote: >> What is the root cause of the annoyance? Mixing macros and inline >> functions does not sound good, but using deeply nested macros do not >> seem to help the debugging situation either. > > That when stepping through code in the debugger you keep enterring/exiting > these one liner inlines, most of them really should be at least by default > considered just as normal statements (e.g. glibc heavily uses artificial > attribute for those, still gdb doesn't hide those by default). so, this is a good candidate for PR to fill against GDB then? It sounds like it would beneficial not just to GCC but to a broader community. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:43 ` Gabriel Dos Reis @ 2012-04-10 16:47 ` Diego Novillo 2012-04-12 19:40 ` Tom Tromey 0 siblings, 1 reply; 182+ messages in thread From: Diego Novillo @ 2012-04-10 16:47 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, David Edelsohn, gcc, Tom Tromey On 4/10/12 12:42 PM, Gabriel Dos Reis wrote: > On Tue, Apr 10, 2012 at 11:39 AM, Jakub Jelinek<jakub@redhat.com> wrote: >>> What is the root cause of the annoyance? Mixing macros and inline >>> functions does not sound good, but using deeply nested macros do not >>> seem to help the debugging situation either. >> >> That when stepping through code in the debugger you keep enterring/exiting >> these one liner inlines, most of them really should be at least by default >> considered just as normal statements (e.g. glibc heavily uses artificial >> attribute for those, still gdb doesn't hide those by default). > > so, this is a good candidate for PR to fill against GDB then? It > sounds like it would > beneficial not just to GCC but to a broader community. Yes, I think there is a bug against gdb already and, in fact, I remember seeing an implementation of some new gdb functionality that would help here. Tom, I'm thinking of that patch on black listing functions. There was also the idea of a command that would only step in the outermost function call of an expression. My memory is hazy, but I know there is some work going on in this area. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:47 ` Diego Novillo @ 2012-04-12 19:40 ` Tom Tromey 2012-04-12 19:42 ` Diego Novillo 0 siblings, 1 reply; 182+ messages in thread From: Tom Tromey @ 2012-04-12 19:40 UTC (permalink / raw) To: Diego Novillo Cc: Gabriel Dos Reis, Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, David Edelsohn, gcc >>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes: Diego> Tom, I'm thinking of that patch on black listing functions. There was Diego> also the idea of a command that would only step in the outermost Diego> function call of an expression. That patch went in. The new command is called "skip". I don't think anybody has worked on stepping into just the outermost function call of an expression. Tom ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-12 19:40 ` Tom Tromey @ 2012-04-12 19:42 ` Diego Novillo 2012-04-12 19:51 ` Tom Tromey 0 siblings, 1 reply; 182+ messages in thread From: Diego Novillo @ 2012-04-12 19:42 UTC (permalink / raw) To: Tom Tromey Cc: Gabriel Dos Reis, Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, David Edelsohn, gcc, Lawrence Crowl On 4/12/12 3:40 PM, Tom Tromey wrote: >>>>>> "Diego" == Diego Novillo<dnovillo@google.com> writes: > > Diego> Tom, I'm thinking of that patch on black listing functions. There was > Diego> also the idea of a command that would only step in the outermost > Diego> function call of an expression. > > That patch went in. The new command is called "skip". Nice! What version of gdb has this support? > I don't think anybody has worked on stepping into just the outermost > function call of an expression. I think we can workaround most issues with 'skip'. Thanks. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-12 19:42 ` Diego Novillo @ 2012-04-12 19:51 ` Tom Tromey 0 siblings, 0 replies; 182+ messages in thread From: Tom Tromey @ 2012-04-12 19:51 UTC (permalink / raw) To: Diego Novillo Cc: Gabriel Dos Reis, Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, David Edelsohn, gcc, Lawrence Crowl >>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes: Diego> Nice! What version of gdb has this support? 7.4. Tom ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:39 ` Jakub Jelinek 2012-04-10 16:43 ` Gabriel Dos Reis @ 2012-04-10 17:37 ` Torvald Riegel 2012-04-10 21:39 ` Miles Bader 2012-04-10 17:54 ` Xinliang David Li 2012-04-11 2:24 ` Lawrence Crowl 3 siblings, 1 reply; 182+ messages in thread From: Torvald Riegel @ 2012-04-10 17:37 UTC (permalink / raw) To: Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, 2012-04-10 at 18:39 +0200, Jakub Jelinek wrote: > On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote: > > > Not to mention it is very questionable if the above stuff is more readable > > > than what we currently have. > > > > The above is just quickly cooked up examples. A carefully designed C++ > > based API can be self documenting and make the client code very > > readable. It is hard to believe that there is no room for improvement > > in GCC. > > Do you have examples? I hate to bring this up, but in my personal experience, getting started with LLVM was _much_ easier than with GCC. LLVM is a much newer codebase, so that's an advantage unrelated to the language. Nonetheless, the grouping/context/ease-of-navigation provided by namespaces, objects, etc. is indeed valuable in my opinion. Torvald ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 17:37 ` Torvald Riegel @ 2012-04-10 21:39 ` Miles Bader 2012-04-10 22:32 ` Bernd Schmidt 0 siblings, 1 reply; 182+ messages in thread From: Miles Bader @ 2012-04-10 21:39 UTC (permalink / raw) To: Torvald Riegel Cc: Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc Torvald Riegel <triegel@redhat.com> writes: > I hate to bring this up, but in my personal experience, getting started > with LLVM was _much_ easier than with GCC. LLVM is a much newer > codebase, so that's an advantage unrelated to the language. I dunno, I've some experience with LLVM as well, and I actually found it rather more difficult to "get started with" than gcc... Part of this is, of course, is that gcc has excellent internals documentation, whereas LLVM's is almost non-existant, but LLVM's much more "proper C++" coding style didn't seem to help a whole lot with making it understandable (and if anything may have made it _worse_). Gcc's code, while insanely nasty in places (reload...), generally seems to be written in a straight-forward manner that I found fairly easy to follow (given some persistence). Of course C++ could help a little in slimming down gcc's code (e.g. using constructors/destructors, etc). -Miles -- Carefully crafted initial estimates reward you not only with reduced computational effort, but also with understanding and increased self-esteem. -- Numerical methods in C, Chapter 9. "Root Finding and Nonlinear Sets of Equations" ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 21:39 ` Miles Bader @ 2012-04-10 22:32 ` Bernd Schmidt 2012-04-10 23:28 ` Eric Botcazou 0 siblings, 1 reply; 182+ messages in thread From: Bernd Schmidt @ 2012-04-10 22:32 UTC (permalink / raw) To: Miles Bader Cc: Torvald Riegel, Jakub Jelinek, Xinliang David Li, Richard Guenther, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 04/10/2012 11:39 PM, Miles Bader wrote: > Torvald Riegel <triegel@redhat.com> writes: >> I hate to bring this up, but in my personal experience, getting started >> with LLVM was _much_ easier than with GCC. LLVM is a much newer >> codebase, so that's an advantage unrelated to the language. > > I dunno, I've some experience with LLVM as well, and I actually found > it rather more difficult to "get started with" than gcc... > > Part of this is, of course, is that gcc has excellent internals > documentation, whereas LLVM's is almost non-existant, but LLVM's much > more "proper C++" coding style didn't seem to help a whole lot with > making it understandable (and if anything may have made it _worse_). My guess would be that there is no right and wrong here, it really depends on what any given individual is familiar with. For example, I certainly wouldn't have guessed that a GET_FIELD_DECL macro would cause problems for autocompletion, since I personally don't use that kind of thing. However, what's important in a project is to pick conventions and stick to them. For example, a lot of people initially loathe the GNU C indentation style, but professional developers adapt themselves to whatever style a project has chosen. There is nothing to be gained but anarchy if personal preferences lead to churn of the "let's reindent" or "let's rewrite in <my favourite language>" kind. In the short term, a partial conversion to C++ gains us nothing. Even ignoring the bugs inevitably caused by any such project, we'll end up with a strange mish-mash of styles for a very long time, which instead of helping anyone can only lead to confusion. I don't see anyone committing to invest the time in converting even an entire subsystem let alone the whole compiler. Maybe a subsystem conversion would be a good thing to try on a branch and then present the results to the community for evaluation. This would be better than lowering the barrier now for all sorts of random but uncoordinated conversion efforts. Bernd ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 22:32 ` Bernd Schmidt @ 2012-04-10 23:28 ` Eric Botcazou 2012-04-10 23:35 ` Gabriel Dos Reis 2012-04-11 7:02 ` Jakub Jelinek 0 siblings, 2 replies; 182+ messages in thread From: Eric Botcazou @ 2012-04-10 23:28 UTC (permalink / raw) To: Bernd Schmidt Cc: gcc, Miles Bader, Torvald Riegel, Jakub Jelinek, Xinliang David Li, Richard Guenther, Gabriel Dos Reis, David Edelsohn, Diego Novillo > In the short term, a partial conversion to C++ gains us nothing. Even > ignoring the bugs inevitably caused by any such project, we'll end up > with a strange mish-mash of styles for a very long time, which instead > of helping anyone can only lead to confusion. I don't see anyone > committing to invest the time in converting even an entire subsystem let > alone the whole compiler. Maybe a subsystem conversion would be a good > thing to try on a branch and then present the results to the community > for evaluation. This would be better than lowering the barrier now for > all sorts of random but uncoordinated conversion efforts. IMO the killer conversion would be vec.[ch], which is a very clever piece of code but is almost impossible to use without copy-and-pasting existing cases. I think that a proper C++ implementation would be a very convincing argument. -- Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 23:28 ` Eric Botcazou @ 2012-04-10 23:35 ` Gabriel Dos Reis 2012-04-11 7:49 ` Eric Botcazou 2012-04-11 7:02 ` Jakub Jelinek 1 sibling, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-10 23:35 UTC (permalink / raw) To: Eric Botcazou Cc: Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Jakub Jelinek, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On Tue, Apr 10, 2012 at 6:27 PM, Eric Botcazou <ebotcazou@adacore.com> wrote: >> In the short term, a partial conversion to C++ gains us nothing. Even >> ignoring the bugs inevitably caused by any such project, we'll end up >> with a strange mish-mash of styles for a very long time, which instead >> of helping anyone can only lead to confusion. I don't see anyone >> committing to invest the time in converting even an entire subsystem let >> alone the whole compiler. Maybe a subsystem conversion would be a good >> thing to try on a branch and then present the results to the community >> for evaluation. This would be better than lowering the barrier now for >> all sorts of random but uncoordinated conversion efforts. > > IMO the killer conversion would be vec.[ch], which is a very clever piece of > code but is almost impossible to use without copy-and-pasting existing cases. > I think that a proper C++ implementation would be a very convincing argument. when you say that, do you mean you would prefer and expect: 1. native C++ style, or 2. you would like the C-style round-about and paraphrasing to remain unperturbed ? The reason I ask is that I expect a "proper" C++ implementation would come with a C++-native style of usage. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 23:35 ` Gabriel Dos Reis @ 2012-04-11 7:49 ` Eric Botcazou 2012-04-11 7:55 ` Gabriel Dos Reis 0 siblings, 1 reply; 182+ messages in thread From: Eric Botcazou @ 2012-04-11 7:49 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Jakub Jelinek, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo > when you say that, do you mean you would prefer and expect: > 1. native C++ style, or > 2. you would like the C-style round-about and paraphrasing to remain > unperturbed > ? > > The reason I ask is that I expect a "proper" C++ implementation would come > with a C++-native style of usage. I don't think that implementing vec.[ch] in C++ would necessarily entail that big a change of style; adding 1 -> per line is OK, adding 3 is something else. -- Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 7:49 ` Eric Botcazou @ 2012-04-11 7:55 ` Gabriel Dos Reis 2012-04-11 8:11 ` Eric Botcazou 0 siblings, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-11 7:55 UTC (permalink / raw) To: Eric Botcazou Cc: Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Jakub Jelinek, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 2:42 AM, Eric Botcazou <ebotcazou@adacore.com> wrote: >> when you say that, do you mean you would prefer and expect: >> 1. native C++ style, or >> 2. you would like the C-style round-about and paraphrasing to remain >> unperturbed >> ? >> >> The reason I ask is that I expect a "proper" C++ implementation would come >> with a C++-native style of usage. > > I don't think that implementing vec.[ch] in C++ would necessarily entail that > big a change of style; adding 1 -> per line is OK, adding 3 is something else. Expressing an idea in C takes me more lines (roughly 2-3 fold) than in C++, so I am a bit puzzled by your observation. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 7:55 ` Gabriel Dos Reis @ 2012-04-11 8:11 ` Eric Botcazou 2012-04-11 11:41 ` Jeff Law 0 siblings, 1 reply; 182+ messages in thread From: Eric Botcazou @ 2012-04-11 8:11 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Jakub Jelinek, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo > Expressing an idea in C takes me more lines (roughly 2-3 fold) than > in C++, so I am a bit puzzled by your observation. We're specifically discussing vec.[ch] here, which is a clever attempt at implementing vectors in C, with macro magic all over the place. -- Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 8:11 ` Eric Botcazou @ 2012-04-11 11:41 ` Jeff Law 0 siblings, 0 replies; 182+ messages in thread From: Jeff Law @ 2012-04-11 11:41 UTC (permalink / raw) To: Eric Botcazou Cc: Gabriel Dos Reis, Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Jakub Jelinek, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On 04/11/2012 02:10 AM, Eric Botcazou wrote: >> Expressing an idea in C takes me more lines (roughly 2-3 fold) than >> in C++, so I am a bit puzzled by your observation. > > We're specifically discussing vec.[ch] here, which is a clever attempt at > implementing vectors in C, with macro magic all over the place. > So can someone convert vec.[ch] on a branch so that we can see exactly what the cost/benefits are for situation that most believe is the most compelling for switching? If that's successful, then propose and convert second hunk on that same branch to show that the benefits aren't isolated to vec.[ch]. I tend to think there's benefit to moving to a subset of C++, but I have some of the concerns raised by Jakub and others. Being able to see firsthand how the code changes from a readability standpoint, how the changes affect compilation speed, bootstrap times, debugability, etc would be a big step towards relieving some of those concerns. Jeff ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 23:28 ` Eric Botcazou 2012-04-10 23:35 ` Gabriel Dos Reis @ 2012-04-11 7:02 ` Jakub Jelinek 2012-04-11 7:46 ` Gabriel Dos Reis 2012-04-11 8:07 ` Eric Botcazou 1 sibling, 2 replies; 182+ messages in thread From: Jakub Jelinek @ 2012-04-11 7:02 UTC (permalink / raw) To: Eric Botcazou Cc: Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Jakub Jelinek, Xinliang David Li, Richard Guenther, Gabriel Dos Reis, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote: > > In the short term, a partial conversion to C++ gains us nothing. Even > > ignoring the bugs inevitably caused by any such project, we'll end up > > with a strange mish-mash of styles for a very long time, which instead > > of helping anyone can only lead to confusion. I don't see anyone > > committing to invest the time in converting even an entire subsystem let > > alone the whole compiler. Maybe a subsystem conversion would be a good > > thing to try on a branch and then present the results to the community > > for evaluation. This would be better than lowering the barrier now for > > all sorts of random but uncoordinated conversion efforts. > > IMO the killer conversion would be vec.[ch], which is a very clever piece of > code but is almost impossible to use without copy-and-pasting existing cases. > I think that a proper C++ implementation would be a very convincing argument. But IMHO not sufficient for a switch. The GCC C++ proponents should do more on a branch to convince. Yes, the syntactic suger for vec.h isn't very nice, but the actual implementation is very clever and heavily tuned for GCC's needs; if we convert to C++ just because of vec.[ch], we open ourselves to what is being discussed in this thread, people who would like to turn GCC codebase into yet another LLVM, which not everybody finds actually very readable and maintainable code, would start doing so. Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 7:02 ` Jakub Jelinek @ 2012-04-11 7:46 ` Gabriel Dos Reis 2012-04-11 7:51 ` Jakub Jelinek 2012-04-11 12:37 ` Bernd Schmidt 2012-04-11 8:07 ` Eric Botcazou 1 sibling, 2 replies; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-11 7:46 UTC (permalink / raw) To: Jakub Jelinek Cc: Eric Botcazou, Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 2:01 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote: >> > In the short term, a partial conversion to C++ gains us nothing. Even >> > ignoring the bugs inevitably caused by any such project, we'll end up >> > with a strange mish-mash of styles for a very long time, which instead >> > of helping anyone can only lead to confusion. I don't see anyone >> > committing to invest the time in converting even an entire subsystem let >> > alone the whole compiler. Maybe a subsystem conversion would be a good >> > thing to try on a branch and then present the results to the community >> > for evaluation. This would be better than lowering the barrier now for >> > all sorts of random but uncoordinated conversion efforts. >> >> IMO the killer conversion would be vec.[ch], which is a very clever piece of >> code but is almost impossible to use without copy-and-pasting existing cases. >> I think that a proper C++ implementation would be a very convincing argument. > > But IMHO not sufficient for a switch. The GCC C++ proponents should do more > on a branch to convince. Yes, the syntactic suger for vec.h isn't very > nice, but the actual implementation is very clever and heavily tuned for > GCC's needs; if we convert to C++ just because of vec.[ch], we open > ourselves to what is being discussed in this thread, people who would like > to turn GCC codebase into yet another LLVM, which not everybody finds > actually very readable and maintainable code, would start doing so. I have been having difficulty following the twists and the turns and the goal post moving. Are you essentially requiring to see GCC rewritten in C++ before we switch to C++? -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 7:46 ` Gabriel Dos Reis @ 2012-04-11 7:51 ` Jakub Jelinek 2012-04-11 12:37 ` Bernd Schmidt 1 sibling, 0 replies; 182+ messages in thread From: Jakub Jelinek @ 2012-04-11 7:51 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Eric Botcazou, Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 02:45:55AM -0500, Gabriel Dos Reis wrote: > On Wed, Apr 11, 2012 at 2:01 AM, Jakub Jelinek <jakub@redhat.com> wrote: > > On Wed, Apr 11, 2012 at 01:27:29AM +0200, Eric Botcazou wrote: > >> > In the short term, a partial conversion to C++ gains us nothing. Even > >> > ignoring the bugs inevitably caused by any such project, we'll end up > >> > with a strange mish-mash of styles for a very long time, which instead > >> > of helping anyone can only lead to confusion. I don't see anyone > >> > committing to invest the time in converting even an entire subsystem let > >> > alone the whole compiler. Maybe a subsystem conversion would be a good > >> > thing to try on a branch and then present the results to the community > >> > for evaluation. This would be better than lowering the barrier now for > >> > all sorts of random but uncoordinated conversion efforts. > >> > >> IMO the killer conversion would be vec.[ch], which is a very clever piece of > >> code but is almost impossible to use without copy-and-pasting existing cases. > >> I think that a proper C++ implementation would be a very convincing argument. > > > > But IMHO not sufficient for a switch. Â The GCC C++ proponents should do more > > on a branch to convince. Â Yes, the syntactic suger for vec.h isn't very > > nice, but the actual implementation is very clever and heavily tuned for > > GCC's needs; if we convert to C++ just because of vec.[ch], we open > > ourselves to what is being discussed in this thread, people who would like > > to turn GCC codebase into yet another LLVM, which not everybody finds > > actually very readable and maintainable code, would start doing so. > > I have been having difficulty following the twists and the turns and > the goal post moving. > Are you essentially requiring to see GCC rewritten in C++ before we > switch to C++? No, but I'd like to see more than just vec.[ch] conversion alone and see what benefits it actually brings to GCC if any with real numbers of what it means to compile time, compilation memory usage, etc. Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 7:46 ` Gabriel Dos Reis 2012-04-11 7:51 ` Jakub Jelinek @ 2012-04-11 12:37 ` Bernd Schmidt 2012-04-11 12:47 ` Richard Guenther ` (2 more replies) 1 sibling, 3 replies; 182+ messages in thread From: Bernd Schmidt @ 2012-04-11 12:37 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jakub Jelinek, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote: > I have been having difficulty following the twists and the turns and > the goal post moving. > Are you essentially requiring to see GCC rewritten in C++ before we > switch to C++? Frankly, despite all this discussion, we still don't really know what the people who insist on a C++ conversion actually want to do. We've seen trivial suggestions like rewriting vec.[ch], which isn't really going to make a big difference in the grand scheme of things, but everything else has remained vague. At the GCC gathering last year we saw a presentation which made me feel like language features had just gone in search of possible applications, which doesn't fill me with a lot of confidence either. So yes, I would like some significant part rewritten in the way the C++ folks would like to see it, so we can actually judge what we will get. And that's moving my personal goal post from "hell no" somewhere closer to what the C++ proponents would like. The incremental approach (tearing down the barrier of stage1 being compiled in C first and then getting things in piecewise) may seem like a path of less resistance, but we can't afford to have a thread like this for every change, and I wouldn't like to see us decide after 100 patches that the end result sucks and we have to either live with it or revert the lot. IMO, gimple might be worth trying to convert, since it's the newest code in gcc and presumably already half-way to what people consider a "modern" style (lots of annoying little functions that get in the way while debugging). But I suspect that when such a branch has been done, it will still come down to personal preference as to which variant is best. This is why I still think the whole thing is deeply misguided, as it's not about objective technical issues, but merely about language preferences, and everyone has a different one. You can't match everyone's taste in a big project, and thus real developers have to adapt to a project, not the other way round. Discussions like this are a toxic distraction from real work. IMO it would be best if we could find a majority of global reviewers to speak out and say once and for all "no, this just isn't happening", so we can drop all this nonsense and get back to improving the compiler for users. The second best thing would be to have a branch with actual work done for us to consider. Bernd ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:37 ` Bernd Schmidt @ 2012-04-11 12:47 ` Richard Guenther 2012-04-11 17:10 ` Xinliang David Li 2012-04-11 13:20 ` Gabriel Dos Reis 2012-04-11 17:08 ` Xinliang David Li 2 siblings, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-11 12:47 UTC (permalink / raw) To: Bernd Schmidt Cc: Gabriel Dos Reis, Jakub Jelinek, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote: >> I have been having difficulty following the twists and the turns and >> the goal post moving. >> Are you essentially requiring to see GCC rewritten in C++ before we >> switch to C++? > > Frankly, despite all this discussion, we still don't really know what > the people who insist on a C++ conversion actually want to do. We've > seen trivial suggestions like rewriting vec.[ch], which isn't really > going to make a big difference in the grand scheme of things, but > everything else has remained vague. At the GCC gathering last year we > saw a presentation which made me feel like language features had just > gone in search of possible applications, which doesn't fill me with a > lot of confidence either. > > So yes, I would like some significant part rewritten in the way the C++ > folks would like to see it, so we can actually judge what we will get. > And that's moving my personal goal post from "hell no" somewhere closer > to what the C++ proponents would like. > > The incremental approach (tearing down the barrier of stage1 being > compiled in C first and then getting things in piecewise) may seem like > a path of less resistance, but we can't afford to have a thread like > this for every change, and I wouldn't like to see us decide after 100 > patches that the end result sucks and we have to either live with it or > revert the lot. > > IMO, gimple might be worth trying to convert, since it's the newest code > in gcc and presumably already half-way to what people consider a > "modern" style (lots of annoying little functions that get in the way > while debugging). > > But I suspect that when such a branch has been done, it will still come > down to personal preference as to which variant is best. This is why I > still think the whole thing is deeply misguided, as it's not about > objective technical issues, but merely about language preferences, and > everyone has a different one. You can't match everyone's taste in a big > project, and thus real developers have to adapt to a project, not the > other way round. Discussions like this are a toxic distraction from real > work. > > IMO it would be best if we could find a majority of global reviewers to > speak out and say once and for all "no, this just isn't happening", so > we can drop all this nonsense and get back to improving the compiler for > users. The second best thing would be to have a branch with actual work > done for us to consider. Frankly I'd say the second best thing is the first best thing. Show us the code! Then we decide. It does not work the other way around. Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:47 ` Richard Guenther @ 2012-04-11 17:10 ` Xinliang David Li 0 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 17:10 UTC (permalink / raw) To: Richard Guenther Cc: Bernd Schmidt, Gabriel Dos Reis, Jakub Jelinek, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 5:47 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Apr 11, 2012 at 2:34 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >> On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote: >>> I have been having difficulty following the twists and the turns and >>> the goal post moving. >>> Are you essentially requiring to see GCC rewritten in C++ before we >>> switch to C++? >> >> Frankly, despite all this discussion, we still don't really know what >> the people who insist on a C++ conversion actually want to do. We've >> seen trivial suggestions like rewriting vec.[ch], which isn't really >> going to make a big difference in the grand scheme of things, but >> everything else has remained vague. At the GCC gathering last year we >> saw a presentation which made me feel like language features had just >> gone in search of possible applications, which doesn't fill me with a >> lot of confidence either. >> >> So yes, I would like some significant part rewritten in the way the C++ >> folks would like to see it, so we can actually judge what we will get. >> And that's moving my personal goal post from "hell no" somewhere closer >> to what the C++ proponents would like. >> >> The incremental approach (tearing down the barrier of stage1 being >> compiled in C first and then getting things in piecewise) may seem like >> a path of less resistance, but we can't afford to have a thread like >> this for every change, and I wouldn't like to see us decide after 100 >> patches that the end result sucks and we have to either live with it or >> revert the lot. >> >> IMO, gimple might be worth trying to convert, since it's the newest code >> in gcc and presumably already half-way to what people consider a >> "modern" style (lots of annoying little functions that get in the way >> while debugging). >> >> But I suspect that when such a branch has been done, it will still come >> down to personal preference as to which variant is best. This is why I >> still think the whole thing is deeply misguided, as it's not about >> objective technical issues, but merely about language preferences, and >> everyone has a different one. You can't match everyone's taste in a big >> project, and thus real developers have to adapt to a project, not the >> other way round. Discussions like this are a toxic distraction from real >> work. >> >> IMO it would be best if we could find a majority of global reviewers to >> speak out and say once and for all "no, this just isn't happening", so >> we can drop all this nonsense and get back to improving the compiler for >> users. The second best thing would be to have a branch with actual work >> done for us to consider. > > Frankly I'd say the second best thing is the first best thing. Show us the > code! Then we decide. It does not work the other way around. > That may not be always the best strategy to move forward. Some level of discussions and agreement can be reached I think. thanks, David > Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:37 ` Bernd Schmidt 2012-04-11 12:47 ` Richard Guenther @ 2012-04-11 13:20 ` Gabriel Dos Reis 2012-04-11 13:29 ` Jakub Jelinek 2012-04-11 17:08 ` Xinliang David Li 2 siblings, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-11 13:20 UTC (permalink / raw) To: Bernd Schmidt Cc: Jakub Jelinek, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 7:34 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote: >> I have been having difficulty following the twists and the turns and >> the goal post moving. >> Are you essentially requiring to see GCC rewritten in C++ before we >> switch to C++? > > Frankly, despite all this discussion, we still don't really know what > the people who insist on a C++ conversion actually want to do. We've > seen trivial suggestions like rewriting vec.[ch], which isn't really > going to make a big difference in the grand scheme of things, but > everything else has remained vague. At the GCC gathering last year we > saw a presentation which made me feel like language features had just > gone in search of possible applications, which doesn't fill me with a > lot of confidence either. > > So yes, I would like some significant part rewritten in the way the C++ > folks would like to see it, so we can actually judge what we will get. > And that's moving my personal goal post from "hell no" somewhere closer > to what the C++ proponents would like. > > The incremental approach (tearing down the barrier of stage1 being > compiled in C first and then getting things in piecewise) may seem like > a path of less resistance, but we can't afford to have a thread like > this for every change, and I wouldn't like to see us decide after 100 > patches that the end result sucks and we have to either live with it or > revert the lot. > > IMO, gimple might be worth trying to convert, since it's the newest code > in gcc and presumably already half-way to what people consider a > "modern" style (lots of annoying little functions that get in the way > while debugging). > > But I suspect that when such a branch has been done, it will still come > down to personal preference as to which variant is best. This is why I > still think the whole thing is deeply misguided, as it's not about > objective technical issues, but merely about language preferences, and > everyone has a different one. You can't match everyone's taste in a big > project, and thus real developers have to adapt to a project, not the > other way round. Discussions like this are a toxic distraction from real > work. > > IMO it would be best if we could find a majority of global reviewers to > speak out and say once and for all "no, this just isn't happening", so > we can drop all this nonsense and get back to improving the compiler for > users. The second best thing would be to have a branch with actual work > done for us to consider. The reason why I am mystified is that the people who seem to argue that it would be pointless to convert the existing codebase to C++ seem to be the same people who insist on seeing significant part of GCC converted to C++ before we switch to *building* stage1 with a C++ compiler. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 13:20 ` Gabriel Dos Reis @ 2012-04-11 13:29 ` Jakub Jelinek 2012-04-11 13:44 ` Gabriel Dos Reis 2012-04-11 14:45 ` David Edelsohn 0 siblings, 2 replies; 182+ messages in thread From: Jakub Jelinek @ 2012-04-11 13:29 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Bernd Schmidt, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote: > The reason why I am mystified is that the people who seem to argue > that it would be pointless to convert the existing codebase to C++ seem > to be the same people who insist on seeing significant part of GCC > converted to C++ before we switch to *building* stage1 with a C++ compiler. What is so puzzling about it? If we don't have a proof that what the GCC in C++ proponents are wanting is actually beneficial for GCC, then just switching building stage1 to C++ is not a step in the right direction, it removes options from those that build GCC or at least makes building GCC unnecessarily bigger hassle. If the switch followed by several conversions to C++ is done on a branch only and the merits are then judged afterwards, we don't do the problematic step on the trunk until it actually gives some benefits (if ever). Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 13:29 ` Jakub Jelinek @ 2012-04-11 13:44 ` Gabriel Dos Reis 2012-04-11 14:45 ` David Edelsohn 1 sibling, 0 replies; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-11 13:44 UTC (permalink / raw) To: Jakub Jelinek Cc: Bernd Schmidt, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Richard Guenther, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 8:28 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote: >> The reason why I am mystified is that the people who seem to argue >> that it would be pointless to convert the existing codebase to C++ seem >> to be the same people who insist on seeing significant part of GCC >> converted to C++ before we switch to *building* stage1 with a C++ compiler. > > What is so puzzling about it? what is puzzling is that if people believe it is pointless to convert the existing codebase to C++, why are they insisting to see that happen before *building* stage1 with a C++ compiler? > If we don't have a proof that what the GCC in > C++ proponents are wanting is actually beneficial for GCC, then just > switching building stage1 to C++ is not a step in the right direction, There is a distinction between converting existing codebase to C++ (which some people think is pointless) and making it possible to add *new functionalities* written in C++. > it removes options from those that build GCC or at least makes building > GCC unnecessarily bigger hassle. If that is your real point, how requiring people to rewrite GCC in C++ before the switch to *build* statge1 with a C++ compiler is going to fix that or address that? > If the switch followed by several conversions to C++ is done on a branch > only and the merits are then judged afterwards, we don't do the problematic > step on the trunk until it actually gives some benefits (if ever). But the primary goal isn't to convert GCC to C++, but to allow new functionalities to be written in C++. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 13:29 ` Jakub Jelinek 2012-04-11 13:44 ` Gabriel Dos Reis @ 2012-04-11 14:45 ` David Edelsohn 2012-04-11 17:41 ` Xinliang David Li 1 sibling, 1 reply; 182+ messages in thread From: David Edelsohn @ 2012-04-11 14:45 UTC (permalink / raw) To: Jakub Jelinek Cc: Gabriel Dos Reis, Bernd Schmidt, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Richard Guenther, Diego Novillo On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote: >> The reason why I am mystified is that the people who seem to argue >> that it would be pointless to convert the existing codebase to C++ seem >> to be the same people who insist on seeing significant part of GCC >> converted to C++ before we switch to *building* stage1 with a C++ compiler. > > What is so puzzling about it? If we don't have a proof that what the GCC in > C++ proponents are wanting is actually beneficial for GCC, then just > switching building stage1 to C++ is not a step in the right direction, > it removes options from those that build GCC or at least makes building > GCC unnecessarily bigger hassle. > If the switch followed by several conversions to C++ is done on a branch > only and the merits are then judged afterwards, we don't do the problematic > step on the trunk until it actually gives some benefits (if ever). Part of the reason this discussion is not reaching a consensus is because it is not addressing the real issue. The challenge is how to make GCC an attractive platform for developers -- how to attract new developers. Among FOSS compilers, LLVM attracts developers. Other than licensing and politics and marketing, the anecdotal comments from developers mention C++ as a technical reason. And other than existing GCC developers who are comfortable with the current C codebase, I think some participants in this thread are concerned that the C++ complaint is a red herring. In other words, some developers resist GCC because it does not match their comfort zone and when asked for a technical reason, C++ is an easy answer. I think some members of the GCC community have a nagging concern that even if GCC goes through the pain of transitioning to C++, it will not move the ball on attracting developers, but will divert resources and will discourage existing developers. We can experiment with C++ for style and debugging and optimization. But, fundamentally, we cannot perform the real experiment which is: Will transitioning GCC to G++ attract more developers to GCC. - David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 14:45 ` David Edelsohn @ 2012-04-11 17:41 ` Xinliang David Li 0 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 17:41 UTC (permalink / raw) To: David Edelsohn Cc: Jakub Jelinek, Gabriel Dos Reis, Bernd Schmidt, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, Richard Guenther, Diego Novillo On Wed, Apr 11, 2012 at 7:44 AM, David Edelsohn <dje.gcc@gmail.com> wrote: > On Wed, Apr 11, 2012 at 9:28 AM, Jakub Jelinek <jakub@redhat.com> wrote: >> On Wed, Apr 11, 2012 at 08:20:05AM -0500, Gabriel Dos Reis wrote: >>> The reason why I am mystified is that the people who seem to argue >>> that it would be pointless to convert the existing codebase to C++ seem >>> to be the same people who insist on seeing significant part of GCC >>> converted to C++ before we switch to *building* stage1 with a C++ compiler. >> >> What is so puzzling about it? If we don't have a proof that what the GCC in >> C++ proponents are wanting is actually beneficial for GCC, then just >> switching building stage1 to C++ is not a step in the right direction, >> it removes options from those that build GCC or at least makes building >> GCC unnecessarily bigger hassle. >> If the switch followed by several conversions to C++ is done on a branch >> only and the merits are then judged afterwards, we don't do the problematic >> step on the trunk until it actually gives some benefits (if ever). > > Part of the reason this discussion is not reaching a consensus is > because it is not addressing the real issue. The challenge is how to > make GCC an attractive platform for developers -- how to attract new > developers. > > Among FOSS compilers, LLVM attracts developers. Other than licensing > and politics and marketing, the anecdotal comments from developers > mention C++ as a technical reason. > > And other than existing GCC developers who are comfortable with the > current C codebase, I think some participants in this thread are > concerned that the C++ complaint is a red herring. In other words, > some developers resist GCC because it does not match their comfort > zone and when asked for a technical reason, C++ is an easy answer. I > think some members of the GCC community have a nagging concern that > even if GCC goes through the pain of transitioning to C++, it will not > move the ball on attracting developers, but will divert resources and > will discourage existing developers. On the other hand, it may also attract additional resources to help out. Not changing anything is certainly not going to help here. thanks, David ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:37 ` Bernd Schmidt 2012-04-11 12:47 ` Richard Guenther 2012-04-11 13:20 ` Gabriel Dos Reis @ 2012-04-11 17:08 ` Xinliang David Li 2 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 17:08 UTC (permalink / raw) To: Bernd Schmidt Cc: Gabriel Dos Reis, Jakub Jelinek, Eric Botcazou, gcc, Miles Bader, Torvald Riegel, Richard Guenther, David Edelsohn, Diego Novillo Mostly agreed. In particular, the discussions should be more concrete -- instead of voting on moving everything to C++ which can create a huge chaos, we should first carefully partition the components that are candidates for the migration (as mentioned by Richard). For instance, 1) core APIs a) tree based b) GIMPLE c) RTL 2) Call Graph component 3) Utility (vec, hash etc) 4) IR streamer and reader 5) IR text dumper 6) optimization driver and pass manager 7) Alias manager 8) Loop managers etc 9) Global Symbol table (do we even have one other than varpool ?) 10) Type table (non existing) 11) Local symbol table (almost non existing) 12) Bitwise data flow framework 13) target model 14) ... and *) CPP and parser (should I mention Clang? :) ) The direction for each component can be voted and the migration plan and roadmaps can also be determined before hand. For C++ifying any component, the owner/driver needs to come up with detailed proposal first. There should also be some new style guidelines. For instance, when migrating to STL container classes, should they be used in 'raw' form, or some kind of GCC style wrapper classes are defined, etc. thanks, David On Wed, Apr 11, 2012 at 5:34 AM, Bernd Schmidt <bernds@codesourcery.com> wrote: > On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote: >> I have been having difficulty following the twists and the turns and >> the goal post moving. >> Are you essentially requiring to see GCC rewritten in C++ before we >> switch to C++? > > Frankly, despite all this discussion, we still don't really know what > the people who insist on a C++ conversion actually want to do. We've > seen trivial suggestions like rewriting vec.[ch], which isn't really > going to make a big difference in the grand scheme of things, but > everything else has remained vague. At the GCC gathering last year we > saw a presentation which made me feel like language features had just > gone in search of possible applications, which doesn't fill me with a > lot of confidence either. > > So yes, I would like some significant part rewritten in the way the C++ > folks would like to see it, so we can actually judge what we will get. > And that's moving my personal goal post from "hell no" somewhere closer > to what the C++ proponents would like. > > The incremental approach (tearing down the barrier of stage1 being > compiled in C first and then getting things in piecewise) may seem like > a path of less resistance, but we can't afford to have a thread like > this for every change, and I wouldn't like to see us decide after 100 > patches that the end result sucks and we have to either live with it or > revert the lot. > > IMO, gimple might be worth trying to convert, since it's the newest code > in gcc and presumably already half-way to what people consider a > "modern" style (lots of annoying little functions that get in the way > while debugging). > > But I suspect that when such a branch has been done, it will still come > down to personal preference as to which variant is best. This is why I > still think the whole thing is deeply misguided, as it's not about > objective technical issues, but merely about language preferences, and > everyone has a different one. You can't match everyone's taste in a big > project, and thus real developers have to adapt to a project, not the > other way round. Discussions like this are a toxic distraction from real > work. > > IMO it would be best if we could find a majority of global reviewers to > speak out and say once and for all "no, this just isn't happening", so > we can drop all this nonsense and get back to improving the compiler for > users. The second best thing would be to have a branch with actual work > done for us to consider. > > > Bernd ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 7:02 ` Jakub Jelinek 2012-04-11 7:46 ` Gabriel Dos Reis @ 2012-04-11 8:07 ` Eric Botcazou 2012-04-11 9:45 ` Richard Guenther 1 sibling, 1 reply; 182+ messages in thread From: Eric Botcazou @ 2012-04-11 8:07 UTC (permalink / raw) To: Jakub Jelinek Cc: Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Richard Guenther, Gabriel Dos Reis, David Edelsohn, Diego Novillo > But IMHO not sufficient for a switch. The GCC C++ proponents should do > more on a branch to convince. Yes, the syntactic suger for vec.h isn't > very nice, but the actual implementation is very clever and heavily tuned > for GCC's needs; if we convert to C++ just because of vec.[ch], we open > ourselves to what is being discussed in this thread, people who would like > to turn GCC codebase into yet another LLVM, which not everybody finds > actually very readable and maintainable code, would start doing so. Maybe, but if we don't convert vec.[ch], there is no point in using C++ at all. We could put in place a strict containment policy: no one is allowed to write non-C code for modules that haven't been explicitly approved. Conversions on a module level are done on a branch and merged into mainline as a whole. And state prominently that there is no long term goal towards a complete rewrite of the compiler in full-blown C++, so that people don't waste time making big plans for such a rewrite. -- Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 8:07 ` Eric Botcazou @ 2012-04-11 9:45 ` Richard Guenther 0 siblings, 0 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-11 9:45 UTC (permalink / raw) To: Eric Botcazou Cc: Jakub Jelinek, Bernd Schmidt, gcc, Miles Bader, Torvald Riegel, Xinliang David Li, Gabriel Dos Reis, David Edelsohn, Diego Novillo On Wed, Apr 11, 2012 at 10:06 AM, Eric Botcazou <ebotcazou@adacore.com> wrote: >> But IMHO not sufficient for a switch. The GCC C++ proponents should do >> more on a branch to convince. Yes, the syntactic suger for vec.h isn't >> very nice, but the actual implementation is very clever and heavily tuned >> for GCC's needs; if we convert to C++ just because of vec.[ch], we open >> ourselves to what is being discussed in this thread, people who would like >> to turn GCC codebase into yet another LLVM, which not everybody finds >> actually very readable and maintainable code, would start doing so. > > Maybe, but if we don't convert vec.[ch], there is no point in using C++ at all. Definitely agreed. > We could put in place a strict containment policy: no one is allowed to write > non-C code for modules that haven't been explicitly approved. Conversions on > a module level are done on a branch and merged into mainline as a whole. And > state prominently that there is no long term goal towards a complete rewrite > of the compiler in full-blown C++, so that people don't waste time making big > plans for such a rewrite. That's why we use C for building stage1 ;) And we should continue to do so until a sufficient part of GCC uses C++ in a way people agree to (thus, people, please start a branch). Richard. > -- > Eric Botcazou ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:39 ` Jakub Jelinek 2012-04-10 16:43 ` Gabriel Dos Reis 2012-04-10 17:37 ` Torvald Riegel @ 2012-04-10 17:54 ` Xinliang David Li 2012-04-11 12:44 ` Marek Polacek 2012-04-11 2:24 ` Lawrence Crowl 3 siblings, 1 reply; 182+ messages in thread From: Xinliang David Li @ 2012-04-10 17:54 UTC (permalink / raw) To: Jakub Jelinek Cc: Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 9:39 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote: >> On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek <jakub@redhat.com> wrote: >> > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: >> >> Class hierarchy is one such feature that is useful. Assuming we have >> >> two hierarchies for gcc: one for values rooted at ValExp, and one for >> >> gimple stmts rooted at GimpInst. >> >> >> >> 1) For IR browsing, >> >> *) all the macro accessors can be eliminated -- a big plus for debugging; >> > >> > Not that clear, if all the macros are replaced by tons of inline functions, >> > the debugging experience can be actually significantly worse. Already some the >> > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH >> > macro are extremely annoying from debugging POV. >> >> What is the root cause of the annoyance? Mixing macros and inline >> functions does not sound good, but using deeply nested macros do not >> seem to help the debugging situation either. > > That when stepping through code in the debugger you keep enterring/exiting > these one liner inlines, most of them really should be at least by default > considered just as normal statements (e.g. glibc heavily uses artificial > attribute for those, still gdb doesn't hide those by default). > >> > Not to mention it is very questionable if the above stuff is more readable >> > than what we currently have. >> >> The above is just quickly cooked up examples. A carefully designed C++ >> based API can be self documenting and make the client code very >> readable. It is hard to believe that there is no room for improvement >> in GCC. > > Do you have examples? E.g. I haven't touched gold, because, while it is a new > C++ codebase, looks completely unreadable to me, similarly libdw C++ stuff. > A carefully designed C based API can be self documenting and make the code > very readable as well, often more so. Personally I think the core APIs should be abstract enough to hide IR details, and high level (possibly multi-level) to allow efficient code manipulation -- be it C or C++. However I think this is really more about the general perceptions and how future developers feel about it. thanks, David > > Jakub ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 17:54 ` Xinliang David Li @ 2012-04-11 12:44 ` Marek Polacek 2012-04-11 16:49 ` Xinliang David Li 0 siblings, 1 reply; 182+ messages in thread From: Marek Polacek @ 2012-04-11 12:44 UTC (permalink / raw) To: Xinliang David Li Cc: Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 10:54:01AM -0700, Xinliang David Li wrote: > manipulation -- be it C or C++. However I think this is really more > about the general perceptions and how future developers feel about it. If GCC would ever be in C++, that would be a very strong argument for me _not_ to touch it. Marek ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 12:44 ` Marek Polacek @ 2012-04-11 16:49 ` Xinliang David Li 0 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 16:49 UTC (permalink / raw) To: Marek Polacek Cc: Jakub Jelinek, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 5:43 AM, Marek Polacek <polacek@redhat.com> wrote: > On Tue, Apr 10, 2012 at 10:54:01AM -0700, Xinliang David Li wrote: >> manipulation -- be it C or C++. However I think this is really more >> about the general perceptions and how future developers feel about it. > > If GCC would ever be in C++, that would be a very strong argument for > me _not_ to touch it. > haha -- I guess a survey in gcc@ would help here :) David > Marek ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:39 ` Jakub Jelinek ` (2 preceding siblings ...) 2012-04-10 17:54 ` Xinliang David Li @ 2012-04-11 2:24 ` Lawrence Crowl 2012-04-11 9:43 ` Richard Guenther 2012-04-12 9:28 ` Chiheng Xu 3 siblings, 2 replies; 182+ messages in thread From: Lawrence Crowl @ 2012-04-11 2:24 UTC (permalink / raw) To: Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote: > That when stepping through code in the debugger you keep > enterring/exiting these one liner inlines, most of them really > should be at least by default considered just as normal statements > (e.g. glibc heavily uses artificial attribute for those, still > gdb doesn't hide those by default). You do want to step into those inline functions, except when you do. In the short term, we can make the debugger behave as though they did not exist. In the longer term, we really want debugging tools that help C++ programmers. One way to get there is to use C++ ourselves. > > The above is just quickly cooked up examples. A carefully > > designed C++ based API can be self documenting and make the > > client code very readable. It is hard to believe that there is > > no room for improvement in GCC. > > Do you have examples? E.g. I haven't touched gold, because, > while it is a new C++ codebase, looks completely unreadable to > me, similarly libdw C++ stuff. A carefully designed C based API > can be self documenting and make the code very readable as well, > often more so. If you just look at any decently sized code base, it'll look pretty much unreadable. The question is how quickly can someone who learns the base vocabulary can produce reasonable modifications. There are many places where C++ can help substantially. For example: () The C++ postfix member function call syntax means that following a chain of attributes is a linear read of the expression. With C function call syntax, you need to read the expression inside out. () C++ has both overloaded functions and member functions, so you can use the same verb to talk about several different kinds of objects. With C function names, we have to invent a new function name for each type. Such names are longer and burden both the author and the reader of the code. () Standard C++ idioms enable mashing program components with ease. The C++ standard library is based on mixing and matching algorithms and data structures, via the common idiom of iterators. () The overloadable operator new means that memory can be _implicitly_ allocated in the right place. () Constructors and destructors reduce the number of places in the code where you need to do explicit memory management. Without garbage collection, leaks are less frequent. With garbage collection, you have much less active garbage, and can run longer between collection runs. Indeed, a conservative collector would be sufficient. () Constructors and destructors also neatly handle actions that must occur in pairs. The classic example is mutex lock and unlock. Within GCC, timevar operations need to happen in pairs. () Class hierarchies (even without virtual functions) can directly represent type relationships, which means that a debugger dump of a C++ type has little unnecessary information, as opposed to the present union of structs approach with GCC trees. () Class hierarchies also mean that programmers can distinguish in the pointer types that a function needs a decl parameter, without having to say 'all trees' versus 'a very specific tree'. The static type checking avoids run-time bugs. I have written compilers in both C and C++. I much prefer the latter. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 2:24 ` Lawrence Crowl @ 2012-04-11 9:43 ` Richard Guenther 2012-04-11 16:47 ` Xinliang David Li ` (2 more replies) 2012-04-12 9:28 ` Chiheng Xu 1 sibling, 3 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-11 9:43 UTC (permalink / raw) To: Lawrence Crowl Cc: Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl <crowl@google.com> wrote: > On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote: >> That when stepping through code in the debugger you keep >> enterring/exiting these one liner inlines, most of them really >> should be at least by default considered just as normal statements >> (e.g. glibc heavily uses artificial attribute for those, still >> gdb doesn't hide those by default). > > You do want to step into those inline functions, except when you do. > In the short term, we can make the debugger behave as though they did > not exist. In the longer term, we really want debugging tools that > help C++ programmers. One way to get there is to use C++ ourselves. Fix the debugger first please. >> > The above is just quickly cooked up examples. A carefully >> > designed C++ based API can be self documenting and make the >> > client code very readable. It is hard to believe that there is >> > no room for improvement in GCC. >> >> Do you have examples? E.g. I haven't touched gold, because, >> while it is a new C++ codebase, looks completely unreadable to >> me, similarly libdw C++ stuff. A carefully designed C based API >> can be self documenting and make the code very readable as well, >> often more so. > > If you just look at any decently sized code base, it'll look pretty > much unreadable. The question is how quickly can someone who learns > the base vocabulary can produce reasonable modifications. > > There are many places where C++ can help substantially. For example: > > () The C++ postfix member function call syntax means that following > a chain of attributes is a linear read of the expression. With C > function call syntax, you need to read the expression inside out. It's a matter of what you are used to (consider LISP). > () C++ has both overloaded functions and member functions, so you can > use the same verb to talk about several different kinds of objects. > With C function names, we have to invent a new function name for > each type. Such names are longer and burden both the author and > the reader of the code. Agreed. Function overloading is one of the nice things that does not automatically make the code-base look "partial C++". Likewise operator overloading can make things like bit_offset = double_int_add (bit_offset, tree_to_double_int (DECL_FIELD_BIT_OFFSET (field))); be just bit_offset = bit_offset + DECL_FIELD_BIT_OFFSET (field); it still looks like C but with some C++ "magic". > () Standard C++ idioms enable mashing program components with ease. > The C++ standard library is based on mixing and matching algorithms > and data structures, via the common idiom of iterators. Sort-of agreed. Though iterator-style (and more so functor style) was never one of my favorite. > () The overloadable operator new means that memory can be > _implicitly_ allocated in the right place. Implicit allocation is bad. In a compiler you want to _see_ where you spend memory. > () Constructors and destructors reduce the number of places in the > code where you need to do explicit memory management. Without garbage > collection, leaks are less frequent. With garbage collection, you > have much less active garbage, and can run longer between collection > runs. Indeed, a conservative collector would be sufficient. Time will tell. > () Constructors and destructors also neatly handle actions that > must occur in pairs. The classic example is mutex lock and unlock. > Within GCC, timevar operations need to happen in pairs. Agreed. > () Class hierarchies (even without virtual functions) can directly > represent type relationships, which means that a debugger dump of > a C++ type has little unnecessary information, as opposed to the > present union of structs approach with GCC trees. In GCC trees only the "base" is a union, and it is so as implementation detail. That gdb does not grok a 'tree' well is because gdb is stupid. All the information is there. > () Class hierarchies also mean that programmers can distinguish > in the pointer types that a function needs a decl parameter, > without having to say 'all trees' versus 'a very specific tree'. > The static type checking avoids run-time bugs. True. In a very limited set of cases. C++ is not powerful enough to express pointer-to-everything-that-would-be-considered-a-gimple-val. Maybe C++ is not the right choice after all? (I suppose C++ concepts would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ... (though is_gimple_val is not be a static property). > I have written compilers in both C and C++. I much prefer the > latter. Did you ever try to convert an existing large C codebase to C++? I would not expect a very good result and rather start from scratch. So I don't see that we ever arrive (or want to arrive) at a pure C++-style GCC. Instead I expect we end up (and desire to end up) with GCC compiled with a C++ compiler that uses C++ features to make the existing style more readable and maintainable. Richard. > -- > Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 9:43 ` Richard Guenther @ 2012-04-11 16:47 ` Xinliang David Li 2012-04-11 20:48 ` Paweł Sikora 2012-04-11 22:34 ` Lawrence Crowl 2 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-11 16:47 UTC (permalink / raw) To: Richard Guenther Cc: Lawrence Crowl, Jakub Jelinek, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 2:43 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Wed, Apr 11, 2012 at 4:24 AM, Lawrence Crowl <crowl@google.com> wrote: >> On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote: >>> That when stepping through code in the debugger you keep >>> enterring/exiting these one liner inlines, most of them really >>> should be at least by default considered just as normal statements >>> (e.g. glibc heavily uses artificial attribute for those, still >>> gdb doesn't hide those by default). >> >> You do want to step into those inline functions, except when you do. >> In the short term, we can make the debugger behave as though they did >> not exist. In the longer term, we really want debugging tools that >> help C++ programmers. One way to get there is to use C++ ourselves. > > Fix the debugger first please. > >>> > The above is just quickly cooked up examples. A carefully >>> > designed C++ based API can be self documenting and make the >>> > client code very readable. It is hard to believe that there is >>> > no room for improvement in GCC. >>> >>> Do you have examples? E.g. I haven't touched gold, because, >>> while it is a new C++ codebase, looks completely unreadable to >>> me, similarly libdw C++ stuff. A carefully designed C based API >>> can be self documenting and make the code very readable as well, >>> often more so. >> >> If you just look at any decently sized code base, it'll look pretty >> much unreadable. The question is how quickly can someone who learns >> the base vocabulary can produce reasonable modifications. >> >> There are many places where C++ can help substantially. For example: >> >> () The C++ postfix member function call syntax means that following >> a chain of attributes is a linear read of the expression. With C >> function call syntax, you need to read the expression inside out. > > It's a matter of what you are used to (consider LISP). > >> () C++ has both overloaded functions and member functions, so you can >> use the same verb to talk about several different kinds of objects. >> With C function names, we have to invent a new function name for >> each type. Such names are longer and burden both the author and >> the reader of the code. > > Agreed. Function overloading is one of the nice things that does not > automatically make the code-base look "partial C++". Likewise > operator overloading can make things like > > bit_offset = double_int_add (bit_offset, > tree_to_double_int > (DECL_FIELD_BIT_OFFSET (field))); > > be just > > bit_offset = bit_offset + DECL_FIELD_BIT_OFFSET (field); > > it still looks like C but with some C++ "magic". > Function overloading is both bless and curse. It makes code look better, but may reduce debuggability. >> () Standard C++ idioms enable mashing program components with ease. >> The C++ standard library is based on mixing and matching algorithms >> and data structures, via the common idiom of iterators. > > Sort-of agreed. Though iterator-style (and more so functor style) was never > one of my favorite. > >> () The overloadable operator new means that memory can be >> _implicitly_ allocated in the right place. > > Implicit allocation is bad. In a compiler you want to _see_ where you > spend memory. overload operator new per class allows memory management easier -- many different allocation policies (e.g pool based) can be easily implemented. > >> () Constructors and destructors reduce the number of places in the >> code where you need to do explicit memory management. Without garbage >> collection, leaks are less frequent. With garbage collection, you >> have much less active garbage, and can run longer between collection >> runs. Indeed, a conservative collector would be sufficient. > > Time will tell. > >> () Constructors and destructors also neatly handle actions that >> must occur in pairs. The classic example is mutex lock and unlock. >> Within GCC, timevar operations need to happen in pairs. > > Agreed. > >> () Class hierarchies (even without virtual functions) can directly >> represent type relationships, which means that a debugger dump of >> a C++ type has little unnecessary information, as opposed to the >> present union of structs approach with GCC trees. > > In GCC trees only the "base" is a union, and it is so as implementation > detail. That gdb does not grok a 'tree' well is because gdb is stupid. > All the information is there. > >> () Class hierarchies also mean that programmers can distinguish >> in the pointer types that a function needs a decl parameter, >> without having to say 'all trees' versus 'a very specific tree'. >> The static type checking avoids run-time bugs. > > True. In a very limited set of cases. C++ is not powerful enough > to express pointer-to-everything-that-would-be-considered-a-gimple-val. > Maybe C++ is not the right choice after all? (I suppose C++ concepts > would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ... > (though is_gimple_val is not be a static property). > >> I have written compilers in both C and C++. I much prefer the >> latter. > > Did you ever try to convert an existing large C codebase to C++? > I would not expect a very good result and rather start from scratch. > So I don't see that we ever arrive (or want to arrive) at a pure C++-style > GCC. Instead I expect we end up (and desire to end up) with GCC > compiled with a C++ compiler that uses C++ features to make the > existing style more readable and maintainable. I like your proposal (from my reading) about keeping core APIs in C, while the rest can be migrated (gradually). thanks, David > > Richard. > >> -- >> Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 9:43 ` Richard Guenther 2012-04-11 16:47 ` Xinliang David Li @ 2012-04-11 20:48 ` Paweł Sikora 2012-04-11 22:34 ` Lawrence Crowl 2 siblings, 0 replies; 182+ messages in thread From: Paweł Sikora @ 2012-04-11 20:48 UTC (permalink / raw) To: gcc Cc: Richard Guenther, Lawrence Crowl, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo On Wednesday 11 of April 2012 11:43:36 Richard Guenther wrote: > > () The overloadable operator new means that memory can be > > _implicitly_ allocated in the right place. > > Implicit allocation is bad. In a compiler you want to _see_ where you > spend memory. in c++ you can overload new/delete operators for each class and track all these allocations with provided allocator. please consider following example: http://pastebin.com/UmBGWMTH you can bind polls, gc or anything else you want for any class and just use the new/delete keywords in sources as usual. in pure C you need to call the right malloc_*/free_* variants for each class. > > () Class hierarchies also mean that programmers can distinguish > > in the pointer types that a function needs a decl parameter, > > without having to say 'all trees' versus 'a very specific tree'. > > The static type checking avoids run-time bugs. > > True. In a very limited set of cases. C++ is not powerful enough > to express pointer-to-everything-that-would-be-considered-a-gimple-val. > Maybe C++ is not the right choice after all? (I suppose C++ concepts > would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ... > (though is_gimple_val is not be a static property). hmm :) the c# provides a nice constraints engine (google the 'where' keyword) and the so-called duck-typing (c# 4.0) which might simplfy the source code that operates on ast nodes. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 9:43 ` Richard Guenther 2012-04-11 16:47 ` Xinliang David Li 2012-04-11 20:48 ` Paweł Sikora @ 2012-04-11 22:34 ` Lawrence Crowl 2 siblings, 0 replies; 182+ messages in thread From: Lawrence Crowl @ 2012-04-11 22:34 UTC (permalink / raw) To: Richard Guenther Cc: Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/11/12, Richard Guenther <richard.guenther@gmail.com> wrote: > On Apr 11, 2012 Lawrence Crowl <crowl@google.com> wrote: > > On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote: > > > That when stepping through code in the debugger you keep > > > enterring/exiting these one liner inlines, most of them > > > really should be at least by default considered just as normal > > > statements (e.g. glibc heavily uses artificial attribute for > > > those, still gdb doesn't hide those by default). > > > > You do want to step into those inline functions, except when > > you do. In the short term, we can make the debugger behave > > as though they did not exist. In the longer term, we really > > want debugging tools that help C++ programmers. One way to > > get there is to use C++ ourselves. > > Fix the debugger first please. And when the debugger says "show us you're using C++ first", what do we do? Based on discussions that I have had, this problem is real. > > > > The above is just quickly cooked up examples. A carefully > > > > designed C++ based API can be self documenting and make > > > > the client code very readable. It is hard to believe that > > > > there is no room for improvement in GCC. > > > > > > Do you have examples? E.g. I haven't touched gold, because, > > > while it is a new C++ codebase, looks completely unreadable to > > > me, similarly libdw C++ stuff. A carefully designed C based > > > API can be self documenting and make the code very readable > > > as well, often more so. > > > > If you just look at any decently sized code base, it'll look > > pretty much unreadable. The question is how quickly can > > someone who learns the base vocabulary can produce reasonable > > modifications. > > > > There are many places where C++ can help substantially. > > For example: > > > > () The C++ postfix member function call syntax means that > > following a chain of attributes is a linear read of the > > expression. With C function call syntax, you need to read the > > expression inside out. > > It's a matter of what you are used to (consider LISP). Certainly. When I was learning to ride horses, every time I would get comfortable, my instructor would say, now do it this other way. It was very uncomfortable, but I got over that and improved my riding. I went through that same transition when I was switching to C++. > > () C++ has both overloaded functions and member functions, > > so you can use the same verb to talk about several different > > kinds of objects. With C function names, we have to invent > > a new function name for each type. Such names are longer and > > burden both the author and the reader of the code. > > Agreed. Function overloading is one of the nice things that > does not automatically make the code-base look "partial C++". > Likewise operator overloading can make things like > > bit_offset = double_int_add (bit_offset, > tree_to_double_int (DECL_FIELD_BIT_OFFSET (field))); > > be just > > bit_offset = bit_offset + DECL_FIELD_BIT_OFFSET (field); > > it still looks like C but with some C++ "magic". > > > () Standard C++ idioms enable mashing program components > > with ease. The C++ standard library is based on mixing and > > matching algorithms and data structures, via the common idiom > > of iterators. > > Sort-of agreed. Though iterator-style (and more so functor style) > was never one of my favorite. > > > () The overloadable operator new means that memory can be > > _implicitly_ allocated in the right place. > > Implicit allocation is bad. In a compiler you want to _see_ > where you spend memory. The operator new is explicit, but the source of the memory for that allocation is implicit. You want to be able to _change_ where you allocate memory without touching half the source base. Operator new overloads enable that precisely because you do not have to say where the memory comes from each time you allocate. > > () Constructors and destructors reduce the number of places in > > the code where you need to do explicit memory management. Without > > garbage collection, leaks are less frequent. With garbage > > collection, you have much less active garbage, and can run > > longer between collection runs. Indeed, a conservative collector > > would be sufficient. > > Time will tell. > > > () Constructors and destructors also neatly handle actions that > > must occur in pairs. The classic example is mutex lock and > > unlock. Within GCC, timevar operations need to happen in pairs. > > Agreed. > > > () Class hierarchies (even without virtual functions) can > > directly represent type relationships, which means that a > > debugger dump of a C++ type has little unnecessary information, > > as opposed to the present union of structs approach with > > GCC trees. > > In GCC trees only the "base" is a union, and it is so as > implementation detail. That gdb does not grok a 'tree' well is > because gdb is stupid. All the information is there. It is an implementation detail that causes friction with the programming environment. > > () Class hierarchies also mean that programmers can distinguish > > in the pointer types that a function needs a decl parameter, > > without having to say 'all trees' versus 'a very specific tree'. > > The static type checking avoids run-time bugs. > > True. In a very limited set of cases. C++ is not powerful enough to > express pointer-to-everything-that-would-be-considered-a-gimple-val. > Maybe C++ is not the right choice after all? (I suppose C++ concepts > would have helped here? pointer-to-tree-that-fulfils-is_gimple_val > ... (though is_gimple_val is not be a static property). > > > I have written compilers in both C and C++. I much prefer > > the latter. > > Did you ever try to convert an existing large C codebase to C++? > I would not expect a very good result and rather start from > scratch. So I don't see that we ever arrive (or want to arrive) > at a pure C++-style GCC. Instead I expect we end up (and desire > to end up) with GCC compiled with a C++ compiler that uses C++ > features to make the existing style more readable and maintainable. While I didn't start the process, I have worked on a C++ compiler that was in transition from a C source base to a C++ source base. The parts of the compiler that didn't need much attention still had a C style. The parts that did need attention, or provided immediate benefit, changed to a C++ style fairly rapidly. Even so, after more than a decade, the compiler had a mix of styles. For all I know, it may still have a mix. One of the changes I made was to convert an enum into a class with member functions, etc. The functional change required more information than the enum could represent. The enum was passed in a single register, while the class was copied for each parameter. Assignment changed from register-to-register into memcpy. So, the instruction overhead for this type jumped substantially. After 20,000 lines modified in this change, I benchmarked the compiler and it was 1% faster. Yes, faster. The reason is that in the process I reorganized the associated parsing and error checking. I took a micro-optimization hit, but won a bigger macro-optimization. The essential benefit of C++ is that it is easier to write and use good abstractions, which enables higher-level changes for higher-level effects. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-11 2:24 ` Lawrence Crowl 2012-04-11 9:43 ` Richard Guenther @ 2012-04-12 9:28 ` Chiheng Xu 2012-04-12 10:30 ` Richard Guenther 1 sibling, 1 reply; 182+ messages in thread From: Chiheng Xu @ 2012-04-12 9:28 UTC (permalink / raw) To: Lawrence Crowl Cc: Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 11, 2012 at 10:24 AM, Lawrence Crowl <crowl@google.com> wrote: > On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote: >> That when stepping through code in the debugger you keep >> enterring/exiting these one liner inlines, most of them really >> should be at least by default considered just as normal statements >> (e.g. glibc heavily uses artificial attribute for those, still >> gdb doesn't hide those by default). > > You do want to step into those inline functions, except when you do. > In the short term, we can make the debugger behave as though they did > not exist. In the longer term, we really want debugging tools that > help C++ programmers. One way to get there is to use C++ ourselves. > >> > The above is just quickly cooked up examples. A carefully >> > designed C++ based API can be self documenting and make the >> > client code very readable. It is hard to believe that there is >> > no room for improvement in GCC. >> >> Do you have examples? E.g. I haven't touched gold, because, >> while it is a new C++ codebase, looks completely unreadable to >> me, similarly libdw C++ stuff. A carefully designed C based API >> can be self documenting and make the code very readable as well, >> often more so. > > If you just look at any decently sized code base, it'll look pretty > much unreadable. The question is how quickly can someone who learns > the base vocabulary can produce reasonable modifications. > > There are many places where C++ can help substantially. For example: > > () The C++ postfix member function call syntax means that following > a chain of attributes is a linear read of the expression. With C > function call syntax, you need to read the expression inside out. > > () C++ has both overloaded functions and member functions, so you can > use the same verb to talk about several different kinds of objects. > With C function names, we have to invent a new function name for > each type. Such names are longer and burden both the author and > the reader of the code. > > () Standard C++ idioms enable mashing program components with ease. > The C++ standard library is based on mixing and matching algorithms > and data structures, via the common idiom of iterators. > > () The overloadable operator new means that memory can be > _implicitly_ allocated in the right place. > > () Constructors and destructors reduce the number of places in the > code where you need to do explicit memory management. Without garbage > collection, leaks are less frequent. With garbage collection, you > have much less active garbage, and can run longer between collection > runs. Indeed, a conservative collector would be sufficient. > > () Constructors and destructors also neatly handle actions that > must occur in pairs. The classic example is mutex lock and unlock. > Within GCC, timevar operations need to happen in pairs. > > () Class hierarchies (even without virtual functions) can directly > represent type relationships, which means that a debugger dump of > a C++ type has little unnecessary information, as opposed to the > present union of structs approach with GCC trees. > > () Class hierarchies also mean that programmers can distinguish > in the pointer types that a function needs a decl parameter, > without having to say 'all trees' versus 'a very specific tree'. > The static type checking avoids run-time bugs. > > I have written compilers in both C and C++. I much prefer the > latter. > What you said sounds correct(mostly) for me. But I think the big benefit of C++ (or any other modern language that support OO design) is that C++ is more consistent with modern software engineering practice : high cohesion and low coupling. C++ allow you to write excellent code more easily than C. Actually, you don't need to write C++ code to use C++. I think you compiler guys should know very well how each line of C++ code is translated to C code, just as C programmers normally know very well how each line of C code is translated to assembly code. So, using which language is not a big deal. It is all about the methodology, the style. You can think in C++, imaging the classes, objects in mind, and use your brain to translate this "in-brain" code to C++ or C code, whatever you like. The reason why GCC's code is very hard to hack is not simple. In part, this is because GCC use a very old, extremely hard to understand build system. In part, this is because GCC developer are more focused on fixing bugs or adding new features, rather than re-factoring GCC's code itself. For example, for a .c file that have 15 years old, people tend to fix its bugs to make it more and more ugly, rather to rewrite it. But I think the big reason is that, GCC tend to have extremely large .c files, which is typical > 6000 LOC. If you look at LLVM, there are rarely source code files that is > 2000 LOC. Typical LLVM source code files have 1000~2000 LOC. Just separating a source code file of 6000 LOC to several small files or file sections of 1000 LOC can improve the code significantly. Why has this not been done before ? GCC developers are reluctant to re-factoring their code may be the reason. And, as the .c file grows, it become even harder to re-factor. Thinking in C++ can help you write smaller, easier to understand, easier to maintain code(C or C++), which have high cohesion and low coupling. And I think the file names of GCC's source can also be changed more friendly to newbies, using some notion of FQN(fully qualified name) may be good. As for plug-in API, I think using C style API is OK. Thinking of Win32 API, the API is C, but it supports C++ notion of object/encapsulation/polymorphism, so you can easily write wrapper API in C++, namely MFC. I mean , to provide a C style API and provide a C++ wrapper library for this API, then you can use both C and C++ in you plug-in. As for experimenting C++ in GCC, I suggest , at first, using C++ only in the internal of a pass implementation or a module, not exposing C++ interface to other part of code. Namely, the interfaces between between modules are still C, but he implementations can be written in either C or C++ or both. And I predict that C++ will not have any positive impact on performance(compile time or run time). -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-12 9:28 ` Chiheng Xu @ 2012-04-12 10:30 ` Richard Guenther 2012-04-14 1:15 ` Chiheng Xu 0 siblings, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-12 10:30 UTC (permalink / raw) To: Chiheng Xu Cc: Lawrence Crowl, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Thu, Apr 12, 2012 at 11:28 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote: > > The reason why GCC's code is very hard to hack is not simple. In part, > this is because GCC use a very old, extremely hard to understand build > system. In part, this is because GCC developer are more focused on > fixing bugs or adding new features, rather than re-factoring GCC's > code itself. For example, for a .c file that have 15 years old, > people tend to fix its bugs to make it more and more ugly, rather to > rewrite it. > > But I think the big reason is that, GCC tend to have extremely large > .c files, which is typical > 6000 LOC. If you look at LLVM, there are > rarely source code files that is > 2000 LOC. Typical LLVM source code > files have 1000~2000 LOC. Just separating a source code file of 6000 > LOC to several small files or file sections of 1000 LOC can improve > the code significantly. Why has this not been done before ? GCC > developers are reluctant to re-factoring their code may be the reason. > And, as the .c file grows, it become even harder to re-factor. > Thinking in C++ can help you write smaller, easier to understand, > easier to maintain code(C or C++), which have high cohesion and low > coupling. > > And I think the file names of GCC's source can also be changed more > friendly to newbies, using some notion of FQN(fully qualified name) > may be good. I think one of the reasons is a tools deficiency - at least subversion (which we use) is not able to track code motion, so if you dig in the revision history you will need more intermediate steps, but more important, rely on 2nd level information (like the ChangeLog entry) to tell where a function was moved from. Still some refactoring happens (I think mostly trying to remove APIs is important). But yes, I think we never renamed files ... I suppose when we start moving things into sub-directories that would be a good time to re-think names. At least subversion can handle file-renames just fine ;) Yes, files are too big - but splitting them is not easy unless you can figure out a hierarchy that you can expose. The largest file is dwarf2out.c with 22825 lines, but the average is more like 2000 (just looking at gcc/*.c files). There are only 23 files bigger than 6000 lines (out of 356), so the situation is not as bad as you paint it. But yes, looking at filenames hardly tells you about its contents anymore. Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-12 10:30 ` Richard Guenther @ 2012-04-14 1:15 ` Chiheng Xu 2012-04-14 6:30 ` Chiheng Xu 2012-04-14 9:08 ` Robert Dewar 0 siblings, 2 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 1:15 UTC (permalink / raw) To: Richard Guenther Cc: Lawrence Crowl, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Thu, Apr 12, 2012 at 6:30 PM, Richard Guenther <richard.guenther@gmail.com> wrote: > > Yes, files are too big - but splitting them is not easy unless you can > figure out > a hierarchy that you can expose. The largest file is dwarf2out.c with > 22825 lines, > but the average is more like 2000 (just looking at gcc/*.c files). > There are only > 23 files bigger than 6000 lines (out of 356), so the situation is not as bad as > you paint it. But yes, looking at filenames hardly tells you about its contents > anymore. > Average file size is not relevant here. You should consider how many code are in files that are big. In gcc/ sub-directory, there are about 600 source files(.c and .h). 63 of them (10%) exceed 100 KB, which contribute over 50% of the total source file size of the directory. 75 of them(13%) is between 50 KB to 100 KB, which contribute 25% of the total source file size of the directory. The rest, 440 or so of them, is below 50 KB, which contribute 75% of the total source file size of the directory. Some of this files are so small that some merging is needed. So, I can say, most of the GCC source code is in large files. And this also hold for language front-ends. -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 1:15 ` Chiheng Xu @ 2012-04-14 6:30 ` Chiheng Xu 2012-04-14 9:08 ` Robert Dewar 1 sibling, 0 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 6:30 UTC (permalink / raw) To: Richard Guenther Cc: Lawrence Crowl, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Sat, Apr 14, 2012 at 9:15 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote: > The rest, 440 or so of them, is below 50 KB, which contribute 75% of The rest, 440 or so of them, is below 50 KB, which contribute 25% of -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 1:15 ` Chiheng Xu 2012-04-14 6:30 ` Chiheng Xu @ 2012-04-14 9:08 ` Robert Dewar 2012-04-14 10:38 ` Chiheng Xu 1 sibling, 1 reply; 182+ messages in thread From: Robert Dewar @ 2012-04-14 9:08 UTC (permalink / raw) To: Chiheng Xu Cc: Richard Guenther, Lawrence Crowl, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/13/2012 9:15 PM, Chiheng Xu wrote: > So, I can say, most of the GCC source code is in large files. > > And this also hold for language front-ends. I see nothing inherently desirable about having all small files. For example, in GNAT, yes, some files are large, sem_ch3 (semantic analysis for chapter 3 stuff which includes all of type handling) is large (over 20,000 lines 750KB, but nothing would be gained (and something would be lost) by trying to split this file up. As long as all your tools can handle large files nicely, and as long as the internal organization of the large file is clean and clear, I see no problem. > ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 9:08 ` Robert Dewar @ 2012-04-14 10:38 ` Chiheng Xu 2012-04-14 11:06 ` Robert Dewar 0 siblings, 1 reply; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 10:38 UTC (permalink / raw) To: Robert Dewar Cc: Richard Guenther, Lawrence Crowl, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar <dewar@adacore.com> wrote: > On 4/13/2012 9:15 PM, Chiheng Xu wrote: > >> So, I can say, most of the GCC source code is in large files. >> >> And this also hold for language front-ends. > > > I see nothing inherently desirable about having all small files. > For example, in GNAT, yes, some files are large, sem_ch3 (semantic > analysis for chapter 3 stuff which includes all of type handling) > is large (over 20,000 lines 750KB, but nothing would be gained > (and something would be lost) by trying to split this file up. > > As long as all your tools can handle large files nicely, and > as long as the internal organization of the large file is > clean and clear, I see no problem. >> >> > Actually, I only partially agree with you on this. And I didn't say smaller is necessarily better. But normally, high cohesion and low coupling code tend not be large. Normally large files tend to export only few highly related entry points. Most of the functions in large file are sub-routines(directly or indirectly) of the entry points. The functions can be divided into several groups or layers, each group or layer can form a conceptual sub-module. I often see GCC developer divide functions in large file into sub-modules by prefix them with sub-module specific prefix and group them together. This is good, but not enough. If the functions in sub-modules are put in separate files, then the code will be more manageable than not doing so. This is because the interfaces/boundaries between sub-modules are more clear, and the code have higher cohesion and lower coupling. -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 10:38 ` Chiheng Xu @ 2012-04-14 11:06 ` Robert Dewar 0 siblings, 0 replies; 182+ messages in thread From: Robert Dewar @ 2012-04-14 11:06 UTC (permalink / raw) To: Chiheng Xu Cc: Richard Guenther, Lawrence Crowl, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/14/2012 6:38 AM, Chiheng Xu wrote: > Actually, I only partially agree with you on this. And I didn't say > smaller is necessarily better. > But normally, high cohesion and low coupling code tend not be large. > Normally large files tend to export only few highly related entry > points. Most of the functions in large file are sub-routines(directly > or indirectly) of the entry points. The functions can be divided into > several groups or layers, each group or layer can form a conceptual > sub-module. I often see GCC developer divide functions in large file > into sub-modules by prefix them with sub-module specific prefix and > group them together. This is good, but not enough. If the functions > in sub-modules are put in separate files, then the code will be more > manageable than not doing so. This is because the > interfaces/boundaries between sub-modules are more clear, and the code > have higher cohesion and lower coupling. I find the claim unconvincing in practice, it is possible to have code in separate files with unclear interfaces and boundaries, and code in single files with perfectly clear interfaces and boundaries. You can claim without evidence that there is a causal relation here but that is simply not the case in my experience. > > ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 8:46 ` Jakub Jelinek 2012-04-10 12:26 ` Michael Matz 2012-04-10 16:23 ` Xinliang David Li @ 2012-04-10 16:42 ` Paweł Sikora 2012-04-10 19:23 ` Dave Korn 2012-04-11 1:01 ` Lawrence Crowl ` (2 subsequent siblings) 5 siblings, 1 reply; 182+ messages in thread From: Paweł Sikora @ 2012-04-10 16:42 UTC (permalink / raw) To: gcc, Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote: > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: > > Class hierarchy is one such feature that is useful. Assuming we have > > two hierarchies for gcc: one for values rooted at ValExp, and one for > > gimple stmts rooted at GimpInst. > > > > 1) For IR browsing, > > *) all the macro accessors can be eliminated -- a big plus for debugging; > > Not that clear, if all the macros are replaced by tons of inline functions, > the debugging experience can be actually significantly worse. debugabilty can be improved with set of gdb python pretty printers which could present gcc's structures in human readable form (instead of union mix). ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 16:42 ` Paweł Sikora @ 2012-04-10 19:23 ` Dave Korn 2012-04-10 20:39 ` Andrew Pinski 2012-04-11 9:27 ` Richard Guenther 0 siblings, 2 replies; 182+ messages in thread From: Dave Korn @ 2012-04-10 19:23 UTC (permalink / raw) To: Paweł Sikora Cc: gcc, Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo On 10/04/2012 17:41, PaweÅ Sikora wrote: > On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote: >> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: >>> Class hierarchy is one such feature that is useful. Assuming we have >>> two hierarchies for gcc: one for values rooted at ValExp, and one for >>> gimple stmts rooted at GimpInst. >>> >>> 1) For IR browsing, *) all the macro accessors can be eliminated -- a >>> big plus for debugging; >> Not that clear, if all the macros are replaced by tons of inline >> functions, the debugging experience can be actually significantly worse. > > debugabilty can be improved with set of gdb python pretty printers which > could present gcc's structures in human readable form (instead of union > mix). > Would that be much different from "call debug_tree(x)" which we already have? cheers, DaveK ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 19:23 ` Dave Korn @ 2012-04-10 20:39 ` Andrew Pinski 2012-04-11 9:27 ` Richard Guenther 1 sibling, 0 replies; 182+ messages in thread From: Andrew Pinski @ 2012-04-10 20:39 UTC (permalink / raw) To: Dave Korn Cc: Paweł Sikora, gcc, Jakub Jelinek, Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo 2012/4/10 Dave Korn <dave.korn.cygwin@gmail.com>: > On 10/04/2012 17:41, Paweł Sikora wrote: >> On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote: >>> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: >>>> Class hierarchy is one such feature that is useful. Assuming we have >>>> two hierarchies for gcc: one for values rooted at ValExp, and one for >>>> gimple stmts rooted at GimpInst. >>>> >>>> 1) For IR browsing, *) all the macro accessors can be eliminated -- a >>>> big plus for debugging; >>> Not that clear, if all the macros are replaced by tons of inline >>> functions, the debugging experience can be actually significantly worse. >> >> debugabilty can be improved with set of gdb python pretty printers which >> could present gcc's structures in human readable form (instead of union >> mix). >> > > Would that be much different from "call debug_tree(x)" which we already have? To the user no but the python pretty printers can be used without a running process and without extra stack size. (both are useful as then we can use with core files and with an overflow stack). Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 19:23 ` Dave Korn 2012-04-10 20:39 ` Andrew Pinski @ 2012-04-11 9:27 ` Richard Guenther 1 sibling, 0 replies; 182+ messages in thread From: Richard Guenther @ 2012-04-11 9:27 UTC (permalink / raw) To: Dave Korn Cc: Paweł Sikora, gcc, Jakub Jelinek, Xinliang David Li, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo 2012/4/10 Dave Korn <dave.korn.cygwin@gmail.com>: > On 10/04/2012 17:41, Paweł Sikora wrote: >> On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote: >>> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: >>>> Class hierarchy is one such feature that is useful. Assuming we have >>>> two hierarchies for gcc: one for values rooted at ValExp, and one for >>>> gimple stmts rooted at GimpInst. >>>> >>>> 1) For IR browsing, *) all the macro accessors can be eliminated -- a >>>> big plus for debugging; >>> Not that clear, if all the macros are replaced by tons of inline >>> functions, the debugging experience can be actually significantly worse. >> >> debugabilty can be improved with set of gdb python pretty printers which >> could present gcc's structures in human readable form (instead of union >> mix). >> > > Would that be much different from "call debug_tree(x)" which we already have? Not really, but it would be easier to customize. I would like to see less debug_* routines in favor of some gdb python code. Heh, maybe we could even use the (non-existant) new plugin introspection API for that! Richard. > cheers, > DaveK > ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 8:46 ` Jakub Jelinek ` (2 preceding siblings ...) 2012-04-10 16:42 ` Paweł Sikora @ 2012-04-11 1:01 ` Lawrence Crowl 2012-04-14 3:40 ` Chiheng Xu 2012-04-14 3:48 ` Chiheng Xu 5 siblings, 0 replies; 182+ messages in thread From: Lawrence Crowl @ 2012-04-11 1:01 UTC (permalink / raw) To: Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On 4/10/12, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: > > Class hierarchy is one such feature that is useful. Assuming we > > have two hierarchies for gcc: one for values rooted at ValExp, > > and one for gimple stmts rooted at GimpInst. > > > > 1) For IR browsing, > > *) all the macro accessors can be eliminated -- a big plus > > for debugging; > > Not that clear, if all the macros are replaced by tons of > inline functions, the debugging experience can be actually > significantly worse. Already some the inline functions used > like tree_operand_length used by TREE_OPERAND_LENGTH macro are > extremely annoying from debugging POV. We have options availble to supress those functions in the debugger. Longer term, better debugger support for C++ is the right thing to do. > > *) gcc implementation has lots of hard coded > > TREE_OPERAND (exp, nn) > > > > e.g. > > exp->as_component_ref().get_field() .. > > exp->as_mem_access().get_base() ... > > exp->as_mem_acesss().get_address() > > --> produces the address expression for memory access > > exp->as_mem_access().get_alias_handle () > > gimple_inst->serialize (&fixup_list) > > --> a virtual function overriden by actual instruction types > > that knows its byte code format. > > That silently assumes we want to change basic GIMPLE/tree data > structures to virtual classes, which is a significant change > that has a significant cost as well. I think he was explicit about virtual functions. By virtual classes did you mean virtual bases or classes with virtual functions? I have not seen a need for virtual classes. In any event, much of this work could be done without virtual functions, though that would not be my choice due to the added overhead and complexity. > E.g. all such changed data structures grow by a virtual pointer > field. Those data structures are heavily optimized for memory > footprint. Not to mention it is very questionable if the above > stuff is more readable than what we currently have. A virtual pointer can reduce the size because the dynamic type can encode quite a bit of information that is currently encoded in bitfields. In addition, while the current data structures are densely packed, they are not necessarily information rich. In the PPH branch, we found that near half the pointers we were streaming were null, which says that many of the fields are unused. This information could be shifted to auxilary tables. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 8:46 ` Jakub Jelinek ` (3 preceding siblings ...) 2012-04-11 1:01 ` Lawrence Crowl @ 2012-04-14 3:40 ` Chiheng Xu 2012-04-14 3:48 ` Chiheng Xu 5 siblings, 0 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 3:40 UTC (permalink / raw) To: Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: >> Class hierarchy is one such feature that is useful. Assuming we have >> two hierarchies for gcc: one for values rooted at ValExp, and one for >> gimple stmts rooted at GimpInst. >> >> 1) For IR browsing, >> *) all the macro accessors can be eliminated -- a big plus for debugging; > > Not that clear, if all the macros are replaced by tons of inline functions, > the debugging experience can be actually significantly worse. Already some the > inline functions used like tree_operand_length used by TREE_OPERAND_LENGTH > macro are extremely annoying from debugging POV. > To avoid debugging POV, in the code, a line of code can be used to convert it to the right pointer type and assign it to a temp variable. This line of code can be optimized away, but temp variable of the right pointer type can improve debuggability. >> *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> >> e.g. >> exp->as_component_ref().get_field() .. >> exp->as_mem_access().get_base() ... >> exp->as_mem_acesss().get_address() --> produces the >> address expression for memory access >> exp->as_mem_access().get_alias_handle () >> >> gimple_inst->serialize (&fixup_list) --> a virtual >> function overriden by actual instruction types that knows its byte >> code format. > > That silently assumes we want to change basic GIMPLE/tree data structures > to virtual classes, which is a significant change that has a significant > cost as well. E.g. all such changed data structures grow by a virtual > pointer field. Those data structures are heavily optimized for memory > footprint. > Not to mention it is very questionable if the above stuff is more readable > than what we currently have. > Agree. -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 8:46 ` Jakub Jelinek ` (4 preceding siblings ...) 2012-04-14 3:40 ` Chiheng Xu @ 2012-04-14 3:48 ` Chiheng Xu 2012-04-15 20:11 ` Chiheng Xu 5 siblings, 1 reply; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 3:48 UTC (permalink / raw) To: Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 4:46 PM, Jakub Jelinek <jakub@redhat.com> wrote: > >> *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> >> e.g. >> exp->as_component_ref().get_field() .. >> exp->as_mem_access().get_base() ... >> exp->as_mem_acesss().get_address() --> produces the >> address expression for memory access >> exp->as_mem_access().get_alias_handle () >> >> gimple_inst->serialize (&fixup_list) --> a virtual >> function overriden by actual instruction types that knows its byte >> code format. > > That silently assumes we want to change basic GIMPLE/tree data structures > to virtual classes, which is a significant change that has a significant > cost as well. E.g. all such changed data structures grow by a virtual > pointer field. Those data structures are heavily optimized for memory > footprint. > Not to mention it is very questionable if the above stuff is more readable > than what we currently have. > And I want to say that tree/gimple/rtl are compiler's data(or state), not compiler's text(or logic), the most important thing about them is how to access their fields. -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-14 3:48 ` Chiheng Xu @ 2012-04-15 20:11 ` Chiheng Xu 2012-04-16 7:48 ` Duncan Sands 2012-04-16 18:53 ` Oleg Endo 0 siblings, 2 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-15 20:11 UTC (permalink / raw) To: Jakub Jelinek Cc: Xinliang David Li, Richard Guenther, Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote: > > And I want to say that tree/gimple/rtl are compiler's data(or state), > not compiler's text(or logic), the most important thing about them is > how to access their fields. > Given the above assumption, now I doubt the necessity of accessor macros or C++ getter/setter method. Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or "tree->get_code()" ? -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-15 20:11 ` Chiheng Xu @ 2012-04-16 7:48 ` Duncan Sands 2012-04-16 9:23 ` Chiheng Xu 2012-04-16 18:53 ` Oleg Endo 1 sibling, 1 reply; 182+ messages in thread From: Duncan Sands @ 2012-04-16 7:48 UTC (permalink / raw) To: gcc >> And I want to say that tree/gimple/rtl are compiler's data(or state), >> not compiler's text(or logic), the most important thing about them is >> how to access their fields. >> > > Given the above assumption, now I doubt the necessity of accessor > macros or C++ getter/setter method. > > Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or > "tree->get_code()" ? On a side note, the dragonegg plugin (which is written in C++) defines /// isa - Return true if the given tree has the specified code. template<enum tree_code code> bool isa(const_tree t) { return TREE_CODE(t) == code; } which lets you write things like if (isa<INTEGRAL_TYPE>(t)) ... and so on. While this is a bit more compact than "if (TREE_CODE(t) == INTEGRAL_TYPE", the main advantage to my mind is that it is a standard C++ idiom that should be natural for many C++ programmers. Ciao, Duncan. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-16 7:48 ` Duncan Sands @ 2012-04-16 9:23 ` Chiheng Xu 0 siblings, 0 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-16 9:23 UTC (permalink / raw) To: Duncan Sands; +Cc: gcc On Mon, Apr 16, 2012 at 3:48 PM, Duncan Sands <baldrick@free.fr> wrote: >>> And I want to say that tree/gimple/rtl are compiler's data(or state), >>> not compiler's text(or logic), the most important thing about them is >>> how to access their fields. >>> >> >> Given the above assumption, now I doubt the necessity of accessor >> macros or C++ getter/setter method. >> >> Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or >> "tree->get_code()" ? > > > On a side note, the dragonegg plugin (which is written in C++) defines > > /// isa - Return true if the given tree has the specified code. > template<enum tree_code code> bool isa(const_tree t) { > return TREE_CODE(t) == code; > } > > which lets you write things like > > if (isa<INTEGRAL_TYPE>(t)) ... > > and so on. > > While this is a bit more compact than "if (TREE_CODE(t) == INTEGRAL_TYPE", Sorry, I totally disagree with you. Your code : /// isa - Return true if the given tree has the specified code. template<enum tree_code code> bool isa(const_tree t) { return TREE_CODE(t) == code; } if (isa<INTEGRAL_TYPE>(t)) ... can be easily replaced by : bool tree_is_a(const_tree t, enum tree_code code) { return TREE_CODE(t) == code; } if(tree_is_a(t, INTEGRAL_TYPE)) ... Your code is like a abuse of template. And, I think GCC developers would more like "if (TREE_CODE(t) == INTEGRAL_TYPE)" style code than the above code. my proposal is if (t->code == INTEGRAL_TYPE){ integral_type p_integer_type = (integral_type) t; do_some_work_integral_type(p_integer_type); } > the main advantage to my mind is that it is a standard C++ idiom that should > be natural for many C++ programmers. > I don't know what you mean by saying the "standard C++ idiom". Do you mean abuse of template or the use of getter/setter method ? In the first case, I will not comment any more. But if you mean that getter/setter method is the "standard C++ idiom", I want to say something. In my understanding, getter/setter methods are used in GUI programming area, where user level C++ objects encapsulate kernel objects. People use getter/setter methods to access the properties of kernel object. C++ object use getter/setter method to capture user's request and forward it to kernel. This is the simple case. Sometimes, C++ GUI library add artificial properties that do not directly correspond to kernel object's properties. The values of these properties are store in C++ object, not in kernel object. Getter methods of these artificial properties are simple, just retrieve the values stored in C++ object. But, setter methods need to do more work, besides storing values in C++ object, normally, several calls to the kernel API is needed to manipulate the kernel object. But in GCC, we don't need to wrap kernel object, and we don't have artificial properties. So, I see no necessity of getter/setter methods. Why GCC currently have TREE_CODE() or TREE_TYPE() macros ? My understanding is that this is because C language does not support inheritance. The field names in base type does not go directly into derived type. In C, "p_derived_type->field_of_base_type" does not work. You must use "p_derived_type->m_base_type.field_of_base_type" . For multilevel of derivation, the expression is even longer. Apparently, this is not as clear as FIELD_OF_BASE_TYPE(p_derived_type). But once you use C++, there will be no such trouble. "p_derived_type->field_of_base_type" just works regardless of the levels of derivation ! -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-15 20:11 ` Chiheng Xu 2012-04-16 7:48 ` Duncan Sands @ 2012-04-16 18:53 ` Oleg Endo 2012-04-17 22:03 ` Chiheng Xu 1 sibling, 1 reply; 182+ messages in thread From: Oleg Endo @ 2012-04-16 18:53 UTC (permalink / raw) To: Chiheng Xu; +Cc: gcc On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote: > On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote: > > > > And I want to say that tree/gimple/rtl are compiler's data(or state), > > not compiler's text(or logic), the most important thing about them is > > how to access their fields. > > > > Given the above assumption, now I doubt the necessity of accessor > macros or C++ getter/setter method. According to my experience, it doesn't take more time/effort to write "tree->code ()" instead of "tree->code" and such getter functions allow for easier refactoring etc. If you omit the getters/setters you can't express things such as immutable objects (well you still could with const ivars but...), and you'll always have to have the ivar... > > Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or > "tree->get_code()" ? What do you mean by efficient? All of them will (most likely) end up as the same machine code. But still, there's a reason why there's a TREE_CODE getter which is supposed to be used instead of writing "tree->base.code" everywhere... Cheers, Oleg ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-16 18:53 ` Oleg Endo @ 2012-04-17 22:03 ` Chiheng Xu 2012-04-18 0:15 ` Oleg Endo 0 siblings, 1 reply; 182+ messages in thread From: Chiheng Xu @ 2012-04-17 22:03 UTC (permalink / raw) To: Oleg Endo; +Cc: gcc On Tue, Apr 17, 2012 at 2:52 AM, Oleg Endo <oleg.endo@t-online.de> wrote: > On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote: >> On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu <chiheng.xu@gmail.com> wrote: >> > >> > And I want to say that tree/gimple/rtl are compiler's data(or state), >> > not compiler's text(or logic), the most important thing about them is >> > how to access their fields. >> > >> >> Given the above assumption, now I doubt the necessity of accessor >> macros or C++ getter/setter method. > > According to my experience, it doesn't take more time/effort to write > "tree->code ()" instead of "tree->code" and such getter functions allow > for easier refactoring etc. If you omit the getters/setters you can't > express things such as immutable objects (well you still could with > const ivars but...), and you'll always have to have the ivar... > Sorry, I don't know what is the benefit of const ivars. But if you use "tree->code" instead of "tree->code()", the compiler know very well whether you intend to read or write a piece of memory. The const-ness is clear. I doubt how the compiler optimizer can further optimize it. >> >> Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or >> "tree->get_code()" ? > > What do you mean by efficient? All of them will (most likely) end up as > the same machine code. By saying "efficient", I probably mean compile time is reduced( macro expansion + optimizing, or inlining + optimizing, are avoided). I also probably mean reduced .h file size( the definitions of accessor macros and C++ getter/setter inline methods, are avoided). -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-17 22:03 ` Chiheng Xu @ 2012-04-18 0:15 ` Oleg Endo 0 siblings, 0 replies; 182+ messages in thread From: Oleg Endo @ 2012-04-18 0:15 UTC (permalink / raw) To: Chiheng Xu; +Cc: gcc On Wed, 2012-04-18 at 06:03 +0800, Chiheng Xu wrote: > > > Sorry, I don't know what is the benefit of const ivars. I didn't say there's a benefit of using const ivars in this hypothetical case. It's just another possible option of doing certain things. > But if you use "tree->code" instead of "tree->code()", the compiler > know very well whether you intend to read or write a piece of memory. > The const-ness is clear. I doubt how the compiler optimizer can > further optimize it. I didn't say that either... > By saying "efficient", I probably mean compile time is reduced( macro > expansion + optimizing, or inlining + optimizing, are avoided). > I also probably mean reduced .h file size( the definitions of accessor > macros and C++ getter/setter inline methods, are avoided). > ...then probably I wasn't aware of the fact that this is about optimizing for compile time. If that's the case, maybe the topic of the thread should be changed to avoid further confusion. Cheers, Oleg ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-09 23:34 ` Xinliang David Li 2012-04-10 8:46 ` Jakub Jelinek @ 2012-04-10 11:14 ` Richard Guenther 2012-04-10 16:33 ` Xinliang David Li 1 sibling, 1 reply; 182+ messages in thread From: Richard Guenther @ 2012-04-10 11:14 UTC (permalink / raw) To: Xinliang David Li Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li <davidxl@google.com> wrote: > On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther > <richard.guenther@gmail.com> wrote: >> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >>> On 04/04/2012 11:06 AM, Richard Guenther wrote: >>>> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined >>>> by transitioning vec.h to a C++ template class, with proper GC support. >>>> (not sure that I can veto anything - heh) >>> >>> I don't think I can veto anything, but I'll go on the record again >>> saying that I don't think this entire plan is a good idea. Write a new >>> project in C++? Absolutely. Convert a large existing one to a different >>> language? A huge waste of time that will distract us for years from >>> actual user-visible changes. >> >> I agree for the idea of converting all of GCC to C++ (whatever that means). >> I disagree for the part making the internal infrastructure easier to use, >> understand and maintain. Which means targeting mostly isolated sub-systems, >> like vec.h (and other various containers), double-int.[ch] (and other various >> way of representing and working with constants). Making tree or gimple a >> C++ class with inheritance and whatever is indeed a huge waste of time >> and existing developer ressources (that, if only because they have to adapt >> and maintain two completely different code-bases over some time). >> >> I expect the GCC core to maintain written in C, compiled by C++. > > > GCC's current C programming APIs (both browsing APIs and > creator/factory APIs) are somewhat primitive and too low level. I > expect switching to C++ can significantly make GCC more modern > looking. It can greatly improve readability and productivity (for > simplifying transformation and instrumentation development). C++ > features should not be be abused (e.g., MI, VI etc), but we should not > miss on basic C++ features. > > Class hierarchy is one such feature that is useful. Assuming we have > two hierarchies for gcc: one for values rooted at ValExp, and one for > gimple stmts rooted at GimpInst. > > 1) For IR browsing, > *) all the macro accessors can be eliminated -- a big plus for debugging; > *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) > > e.g. > exp->as_component_ref().get_field() .. > exp->as_mem_access().get_base() ... > exp->as_mem_acesss().get_address() --> produces the > address expression for memory access > exp->as_mem_access().get_alias_handle () > > gimple_inst->serialize (&fixup_list) --> a virtual > function overriden by actual instruction types that knows its byte > code format. > > For experienced GCC developers, current APIs won't a problem at all -- > but it does become a big minus for newbies and in the long run will > hurt gcc community. > > 2) IR manipulation APIs -- the problem seems more serious. It seems > GCC prefers low level APIs so that incremental update of derived data > (control flow, SSA) can be easier -- but that does not have to be the > case -- high level APIs can hide most of the update from the > programmer. > > Example: Create a a simple assignment instruction from a load (this > example comes from Asan implementation in gcc by Kostya) > > t = build1 (INDIRECT_REF, some_type, > build1 (VIEW_CONVERT_EXPR, some_type, addr)); > t = force_gimple_operand (t, &stmts, false, NULL_TREE); > gimple_seq_add_seq (&seq, stmts); > the_value = make_rename_temp (shadow_type, "__var_name"); > g = gimple_build_assign (the_value, t); > nm = make_ssa_name (the_value, g); > gimple_assign_set_lhs (g, nm); > > > This can be as simple as (by hiding the gimplification, ssa name creation etc) > > new_assign_insn = gimple::new_load_insn (INDIRECT_REF, some_type, addr_exp); > new_assign_insn->get_lhs()->as_ssa_name()->get_val_decl()->setname("..."); > > The creator interface can also take a form that accepts the addr_insn > that produces the address. > > Another example: > > Instrument a BB1 so that it is guarded: > > if (counts > sampling_rate) // BB0 > { > counts = 0; > ORIGINAL BB1 code > } // BB2 > > > It can be as simple as the following: > > basic_block bb0, bb1; > > gimple_br_inst = gimple::new_cond_br (value:new_cmp_exp (....), > bb1, > /* taken branch* / > > &bb2, /* fall through */ > > &bb2, /* merge point */ > > &bb0 /* New predecessor */); > reset_count = gimple:new_store_insn (..., bb1, insert_before); > > > If the current APIs are used to do the coding, it will take how X > times more API calls which is non-readable for human beings. The above is non-readable to me neither. That we miss a helper to do the split-the-cfg-here-with-a-conditional-branch-and-bbs-for-true-false does not mean that such helper has to use whatever fancy C++ interface. What's wrong with a C helper for the above? Why is it easier in C++ at all? And you want to contribute the 10+ man years to consistently(!) transition GCC to such API? Sorry, but you cannot magically transform GCC to something more modern. Thus it will be isolated "leaf" modules that will see conversion. I don't hold my breath for even converting the gimple bits, not to even think about trees (or RTL). Sorry. Richard. > > thanks, > > David > >> >>> I also find debugging C++ in gdb somewhat more annoying than debugging >>> plain C, and at the moment I always go back to a stage1 compiler. >> >> Indeed - I'd be worried if my debugging efficiency decreases by more than 5%. >> >> Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-10 11:14 ` Richard Guenther @ 2012-04-10 16:33 ` Xinliang David Li 0 siblings, 0 replies; 182+ messages in thread From: Xinliang David Li @ 2012-04-10 16:33 UTC (permalink / raw) To: Richard Guenther Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Tue, Apr 10, 2012 at 4:14 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li <davidxl@google.com> wrote: >> On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther >> <richard.guenther@gmail.com> wrote: >>> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >>>> On 04/04/2012 11:06 AM, Richard Guenther wrote: >>>>> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined >>>>> by transitioning vec.h to a C++ template class, with proper GC support. >>>>> (not sure that I can veto anything - heh) >>>> >>>> I don't think I can veto anything, but I'll go on the record again >>>> saying that I don't think this entire plan is a good idea. Write a new >>>> project in C++? Absolutely. Convert a large existing one to a different >>>> language? A huge waste of time that will distract us for years from >>>> actual user-visible changes. >>> >>> I agree for the idea of converting all of GCC to C++ (whatever that means). >>> I disagree for the part making the internal infrastructure easier to use, >>> understand and maintain. Which means targeting mostly isolated sub-systems, >>> like vec.h (and other various containers), double-int.[ch] (and other various >>> way of representing and working with constants). Making tree or gimple a >>> C++ class with inheritance and whatever is indeed a huge waste of time >>> and existing developer ressources (that, if only because they have to adapt >>> and maintain two completely different code-bases over some time). >>> >>> I expect the GCC core to maintain written in C, compiled by C++. >> >> >> GCC's current C programming APIs (both browsing APIs and >> creator/factory APIs) are somewhat primitive and too low level. I >> expect switching to C++ can significantly make GCC more modern >> looking. It can greatly improve readability and productivity (for >> simplifying transformation and instrumentation development). C++ >> features should not be be abused (e.g., MI, VI etc), but we should not >> miss on basic C++ features. >> >> Class hierarchy is one such feature that is useful. Assuming we have >> two hierarchies for gcc: one for values rooted at ValExp, and one for >> gimple stmts rooted at GimpInst. >> >> 1) For IR browsing, >> *) all the macro accessors can be eliminated -- a big plus for debugging; >> *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) >> >> e.g. >> exp->as_component_ref().get_field() .. >> exp->as_mem_access().get_base() ... >> exp->as_mem_acesss().get_address() --> produces the >> address expression for memory access >> exp->as_mem_access().get_alias_handle () >> >> gimple_inst->serialize (&fixup_list) --> a virtual >> function overriden by actual instruction types that knows its byte >> code format. >> >> For experienced GCC developers, current APIs won't a problem at all -- >> but it does become a big minus for newbies and in the long run will >> hurt gcc community. >> >> 2) IR manipulation APIs -- the problem seems more serious. It seems >> GCC prefers low level APIs so that incremental update of derived data >> (control flow, SSA) can be easier -- but that does not have to be the >> case -- high level APIs can hide most of the update from the >> programmer. >> >> Example: Create a a simple assignment instruction from a load (this >> example comes from Asan implementation in gcc by Kostya) >> >> t = build1 (INDIRECT_REF, some_type, >> build1 (VIEW_CONVERT_EXPR, some_type, addr)); >> t = force_gimple_operand (t, &stmts, false, NULL_TREE); >> gimple_seq_add_seq (&seq, stmts); >> the_value = make_rename_temp (shadow_type, "__var_name"); >> g = gimple_build_assign (the_value, t); >> nm = make_ssa_name (the_value, g); >> gimple_assign_set_lhs (g, nm); >> >> >> This can be as simple as (by hiding the gimplification, ssa name creation etc) >> >> new_assign_insn = gimple::new_load_insn (INDIRECT_REF, some_type, addr_exp); >> new_assign_insn->get_lhs()->as_ssa_name()->get_val_decl()->setname("..."); >> >> The creator interface can also take a form that accepts the addr_insn >> that produces the address. >> >> Another example: >> >> Instrument a BB1 so that it is guarded: >> >> if (counts > sampling_rate) // BB0 >> { >> counts = 0; >> ORIGINAL BB1 code >> } // BB2 >> >> >> It can be as simple as the following: >> >> basic_block bb0, bb1; >> >> gimple_br_inst = gimple::new_cond_br (value:new_cmp_exp (....), >> bb1, >> /* taken branch* / >> >> &bb2, /* fall through */ >> >> &bb2, /* merge point */ >> >> &bb0 /* New predecessor */); >> reset_count = gimple:new_store_insn (..., bb1, insert_before); >> >> >> If the current APIs are used to do the coding, it will take how X >> times more API calls which is non-readable for human beings. > > The above is non-readable to me neither. That we miss a helper > to do the split-the-cfg-here-with-a-conditional-branch-and-bbs-for-true-false > does not mean that such helper has to use whatever fancy C++ interface. > What's wrong with a C helper for the above? Why is it easier in C++ at all? yes -- I lumped two things together. I care about the high level APIs more than I care about C++. > > And you want to contribute the 10+ man years to consistently(!) transition > GCC to such API? > Transitioning to wrapper APIs above is certainly worth the effort. It make GCC code lean and mean. Currently there are lots of code duplication with cut&paste. > Sorry, but you cannot magically transform GCC to something more modern. > Thus it will be isolated "leaf" modules that will see conversion. I don't hold > my breath for even converting the gimple bits, not to even think about trees > (or RTL). > > Sorry. No need to be sorry. I don't see it happening magically either. If it needs to be done, it will be carefully designed and incremental. thanks, David > > Richard. > >> >> thanks, >> >> David >> >>> >>>> I also find debugging C++ in gdb somewhat more annoying than debugging >>>> plain C, and at the moment I always go back to a stage1 compiler. >>> >>> Indeed - I'd be worried if my debugging efficiency decreases by more than 5%. >>> >>> Richard. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 12:04 ` Richard Guenther ` (2 preceding siblings ...) 2012-04-09 23:34 ` Xinliang David Li @ 2012-04-14 2:41 ` Chiheng Xu 3 siblings, 0 replies; 182+ messages in thread From: Chiheng Xu @ 2012-04-14 2:41 UTC (permalink / raw) To: Richard Guenther Cc: Bernd Schmidt, Gabriel Dos Reis, David Edelsohn, Diego Novillo, gcc On Wed, Apr 4, 2012 at 8:04 PM, Richard Guenther <richard.guenther@gmail.com> wrote: > > I agree for the idea of converting all of GCC to C++ (whatever that means). > I disagree for the part making the internal infrastructure easier to use, > understand and maintain. Which means targeting mostly isolated sub-systems, > like vec.h (and other various containers), double-int.[ch] (and other various > way of representing and working with constants). Making tree or gimple a > C++ class with inheritance and whatever is indeed a huge waste of time > and existing developer ressources (that, if only because they have to adapt > and maintain two completely different code-bases over some time). > > I expect the GCC core to maintain written in C, compiled by C++. > Making tree or gimple or even rtl a C++ class with inheritance should be easy. Current functions and accessor macros can be preserved. for example: C: typedef struct base_type_tag { int m_data_1; } base_type; typedef struct derived_type_tag { struct base_type base; int m_data_2; } derived_type; #define BASE_TYPE_ACCESSOR_MACRO_1(a) ... #define DERIVED_TYPE_ACCESSOR_MACRO_2(a) ... int base_type _func_1(base_type * p_base, ...) { } int derived_type_func_2(derived_type * p_derived, ...) { } C++: class base_type { int m_data_1; getter_1(); setter_1(); method_1(); }; class derived_type : public base_type { int m_data_2; getter_2(); setter_2(); method_2(); }; #define BASE_TYPE_ACCESSOR_MACRO_1(a) ... #define DERIVED_TYPE_ACCESSOR_MACRO_2(a) ... int base_type _func_1(base_type * p_base, ...) { } int derived_type_func_2(derived_type * p_derived, ...) { } base_type::getter_1() { } base_type::setter_1() { } base_type::method_1() { } derived_type::getter_2() { } derived_type::setter_2() { } derived_type::method_2() { } -- Chiheng Xu ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 1:13 ` David Edelsohn 2012-04-04 4:00 ` Ian Lance Taylor 2012-04-04 8:32 ` Gabriel Dos Reis @ 2012-04-04 11:22 ` Diego Novillo 2 siblings, 0 replies; 182+ messages in thread From: Diego Novillo @ 2012-04-04 11:22 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc On 4/3/12 9:13 PM, David Edelsohn wrote: > I appreciate the motivation, but this may cause major problems on > non-GNU/Linux platforms. Testing on all primary targets is not > enough. I can test on other targets, as well. What targets do you have in mind? If I don't have access to them, I'll need volunteers to test my patch. Diego. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-03 17:38 Switching to C++ by default in 4.8 Diego Novillo 2012-04-03 19:39 ` Paweł Sikora 2012-04-04 1:13 ` David Edelsohn @ 2012-04-04 7:07 ` Tristan Gingold 2012-04-04 13:13 ` Ian Lance Taylor 2 siblings, 1 reply; 182+ messages in thread From: Tristan Gingold @ 2012-04-04 7:07 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc, Ian Lance Taylor, Lawrence Crowl On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote: > > We would like to start the process to make GCC 4.8 build in C++ mode by default. > > The mechanics of the change are simple enough. I volunteer to test changing the default on all primary targets (assuming I can get them from the GCC build farm). Is it already possible to build stage1 with c++ ? The VMS targets are not yet ready with build in C++ mode. This target is somewhat special because it can be built only with a cross-compiler (we don't support regular 3 stages native builds because there is no complete and working well enough UNIX emulation tools). I started to build g++ (and gfortran) for ia64 and alpha VMS in order to prepare this transition, but having a soft path would be better to me. (Clearly VMS is not a blocking target for the GCC community - that's not the point). Tristan. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 7:07 ` Tristan Gingold @ 2012-04-04 13:13 ` Ian Lance Taylor 2012-04-04 13:32 ` Tristan Gingold 0 siblings, 1 reply; 182+ messages in thread From: Ian Lance Taylor @ 2012-04-04 13:13 UTC (permalink / raw) To: Tristan Gingold; +Cc: Diego Novillo, gcc, Lawrence Crowl Tristan Gingold <gingold@adacore.com> writes: > On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote: > >> >> We would like to start the process to make GCC 4.8 build in C++ mode by default. >> >> The mechanics of the change are simple enough. I volunteer to test changing the default on all primary targets (assuming I can get them from the GCC build farm). > > Is it already possible to build stage1 with c++ ? Yes. There are two relevant configure options: --enable-build-with-cxx and --enable-build-poststage1-with-cxx. Currently the first defaults to no and the second defaults to yes. The change in question would be making the first default to yes. > The VMS targets are not yet ready with build in C++ mode. This target > is somewhat special because it can be built only with a cross-compiler > (we don't support regular 3 stages native builds because there is no > complete and working well enough UNIX emulation tools). > > I started to build g++ (and gfortran) for ia64 and alpha VMS in order > to prepare this transition, but having a soft path would be better to > me. Sounds like you would need to have a C++ cross-compiler for VMS. What are the issues with making that work? Ian ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 13:13 ` Ian Lance Taylor @ 2012-04-04 13:32 ` Tristan Gingold 2012-04-04 14:37 ` Gabriel Dos Reis 0 siblings, 1 reply; 182+ messages in thread From: Tristan Gingold @ 2012-04-04 13:32 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Diego Novillo, gcc, Lawrence Crowl On Apr 4, 2012, at 3:12 PM, Ian Lance Taylor wrote: > Tristan Gingold <gingold@adacore.com> writes: > >> On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote: >> >>> >>> We would like to start the process to make GCC 4.8 build in C++ mode by default. >>> >>> The mechanics of the change are simple enough. I volunteer to test changing the default on all primary targets (assuming I can get them from the GCC build farm). >> >> Is it already possible to build stage1 with c++ ? > > Yes. There are two relevant configure options: --enable-build-with-cxx Ah thanks, I missed this option. > and --enable-build-poststage1-with-cxx. Currently the first defaults to > no and the second defaults to yes. The change in question would be > making the first default to yes. > > >> The VMS targets are not yet ready with build in C++ mode. This target >> is somewhat special because it can be built only with a cross-compiler >> (we don't support regular 3 stages native builds because there is no >> complete and working well enough UNIX emulation tools). >> >> I started to build g++ (and gfortran) for ia64 and alpha VMS in order >> to prepare this transition, but having a soft path would be better to >> me. > > Sounds like you would need to have a C++ cross-compiler for VMS. What > are the issues with making that work? For ia64, g++ is working on simple examples (and for the testsuite). But building gcc will be a better test. For Alpha, gas crashes during libstdc++ build. From initial investigation, this looks manageable. But Alpha object format is quite old, and has no support for comdat (but weak symbols should work). I only have worked on g++ for Alpha for a few days. Tristan. ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 13:32 ` Tristan Gingold @ 2012-04-04 14:37 ` Gabriel Dos Reis 2012-04-04 14:52 ` Tristan Gingold 0 siblings, 1 reply; 182+ messages in thread From: Gabriel Dos Reis @ 2012-04-04 14:37 UTC (permalink / raw) To: Tristan Gingold; +Cc: Ian Lance Taylor, Diego Novillo, gcc, Lawrence Crowl On Wed, Apr 4, 2012 at 8:32 AM, Tristan Gingold <gingold@adacore.com> wrote: > For Alpha, gas crashes during libstdc++ build. From initial investigation, this looks manageable. But Alpha object format is quite old, and has no support for comdat (but weak symbols should work). I believe weak symbols should suffice, if the object file does not have comdat. -- Gaby ^ permalink raw reply [flat|nested] 182+ messages in thread
* Re: Switching to C++ by default in 4.8 2012-04-04 14:37 ` Gabriel Dos Reis @ 2012-04-04 14:52 ` Tristan Gingold 0 siblings, 0 replies; 182+ messages in thread From: Tristan Gingold @ 2012-04-04 14:52 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Ian Lance Taylor, Diego Novillo, gcc, Lawrence Crowl On Apr 4, 2012, at 4:37 PM, Gabriel Dos Reis wrote: > On Wed, Apr 4, 2012 at 8:32 AM, Tristan Gingold <gingold@adacore.com> wrote: > >> For Alpha, gas crashes during libstdc++ build. From initial investigation, this looks manageable. But Alpha object format is quite old, and has no support for comdat (but weak symbols should work). > > I believe weak symbols should suffice, if the object file does not have comdat. That's also my understanding from reading various gcc pieces. But these features (aliases and weak) was never well-tested in the Alpha VMS case. Tristan. ^ permalink raw reply [flat|nested] 182+ messages in thread
end of thread, other threads:[~2012-04-20 20:14 UTC | newest] Thread overview: 182+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-03 17:38 Switching to C++ by default in 4.8 Diego Novillo 2012-04-03 19:39 ` Paweł Sikora 2012-04-03 20:52 ` Ian Lance Taylor 2012-04-03 21:34 ` Paweł Sikora 2012-04-20 20:14 ` Joseph S. Myers 2012-04-04 5:19 ` Basile Starynkevitch 2012-04-04 1:13 ` David Edelsohn 2012-04-04 4:00 ` Ian Lance Taylor 2012-04-04 4:42 ` Miles Bader 2012-04-04 8:32 ` Gabriel Dos Reis 2012-04-04 9:06 ` Richard Guenther 2012-04-04 9:10 ` Gabriel Dos Reis 2012-04-04 9:15 ` Gabriel Dos Reis 2012-04-04 9:59 ` Richard Guenther 2012-04-04 10:02 ` Richard Guenther 2012-04-04 11:20 ` Diego Novillo 2012-04-04 11:38 ` Richard Guenther 2012-04-04 14:12 ` Tom Tromey 2012-04-04 14:45 ` Richard Guenther 2012-04-04 14:48 ` Richard Guenther 2012-04-14 1:35 ` Chiheng Xu 2012-04-14 9:09 ` Robert Dewar 2012-04-14 10:03 ` Chiheng Xu 2012-04-14 11:13 ` Robert Dewar 2012-04-14 11:41 ` Jonathan Wakely 2012-04-14 10:39 ` Gabriel Dos Reis 2012-04-14 11:08 ` Robert Dewar 2012-04-16 9:37 ` Chiheng Xu 2012-04-16 9:38 ` Jonathan Wakely 2012-04-17 9:11 ` Robert Dewar 2012-04-05 12:40 ` Pedro Lamarão 2012-04-05 13:05 ` Richard Guenther 2012-04-05 14:21 ` Diego Novillo 2012-04-05 14:24 ` Richard Guenther 2012-04-05 14:36 ` Diego Novillo 2012-04-05 20:17 ` David Edelsohn 2012-04-05 20:36 ` Gabriel Dos Reis 2012-04-06 0:11 ` David Edelsohn 2012-04-09 10:37 ` Richard Guenther 2012-04-09 15:07 ` David Edelsohn 2012-04-10 22:04 ` Pedro Lamarão 2012-04-10 22:56 ` Diego Novillo 2012-04-04 11:53 ` Bernd Schmidt 2012-04-04 12:04 ` Richard Guenther 2012-04-04 14:59 ` Diego Novillo 2012-04-04 17:54 ` Lawrence Crowl 2012-04-05 9:18 ` Richard Guenther 2012-04-05 20:07 ` Lawrence Crowl 2012-04-09 10:40 ` Richard Guenther 2012-04-09 17:56 ` Lawrence Crowl 2012-04-09 18:22 ` Jakub Jelinek 2012-04-09 18:52 ` Lawrence Crowl 2012-04-09 18:54 ` Jakub Jelinek 2012-04-09 21:15 ` Lawrence Crowl 2012-04-10 11:09 ` Richard Guenther 2012-04-11 1:36 ` Lawrence Crowl 2012-04-11 6:55 ` Jakub Jelinek 2012-04-13 23:26 ` Dave Korn 2012-04-11 9:32 ` Richard Guenther 2012-04-14 3:07 ` Chiheng Xu 2012-04-14 3:04 ` Chiheng Xu 2012-04-14 21:25 ` Lawrence Crowl 2012-04-09 23:34 ` Xinliang David Li 2012-04-10 8:46 ` Jakub Jelinek 2012-04-10 12:26 ` Michael Matz 2012-04-10 15:51 ` David Edelsohn 2012-04-10 16:05 ` Gabriel Dos Reis 2012-04-10 16:13 ` Diego Novillo 2012-04-11 9:17 ` Richard Guenther 2012-04-11 16:35 ` Xinliang David Li 2012-04-10 16:12 ` Xinliang David Li 2012-04-10 16:24 ` Michael Matz 2012-04-10 17:08 ` Xinliang David Li 2012-04-10 17:29 ` Torvald Riegel 2012-04-10 18:00 ` Eric Botcazou 2012-04-10 19:56 ` Torvald Riegel 2012-04-10 21:13 ` Eric Botcazou 2012-04-10 21:29 ` Torvald Riegel 2012-04-10 23:15 ` Eric Botcazou 2012-04-11 20:57 ` Torvald Riegel 2012-04-11 21:15 ` Eric Botcazou 2012-04-11 21:43 ` Torvald Riegel 2012-04-13 23:33 ` Dave Korn 2012-04-11 9:24 ` Richard Guenther 2012-04-11 12:58 ` Torvald Riegel 2012-04-11 13:13 ` Richard Guenther 2012-04-11 13:23 ` Gabriel Dos Reis 2012-04-11 14:19 ` Torvald Riegel 2012-04-11 17:24 ` Xinliang David Li 2012-04-11 18:17 ` Andrew Pinski 2012-04-11 20:02 ` Xinliang David Li 2012-04-12 5:08 ` Ian Lance Taylor 2012-04-12 6:12 ` Miles Bader 2012-04-12 6:22 ` James Dennett 2012-04-11 18:26 ` Jonathan Wakely 2012-04-11 18:41 ` Pedro Alves 2012-04-11 20:00 ` Xinliang David Li 2012-04-11 20:05 ` Jonathan Wakely 2012-04-12 5:10 ` Ian Lance Taylor [not found] ` <12130397.ZsTVnyYbKR@pawels> 2012-04-11 13:14 ` Richard Guenther 2012-04-11 13:24 ` Bernd Schmidt 2012-04-11 17:31 ` Xinliang David Li 2012-04-11 18:37 ` Basile Starynkevitch 2012-04-11 18:52 ` Gabriel Dos Reis 2012-04-11 20:14 ` Xinliang David Li 2012-04-12 15:51 ` Ludovic Courtès 2012-04-13 23:45 ` Dave Korn 2012-04-11 14:41 ` Jonathan Wakely 2012-04-11 17:13 ` Xinliang David Li 2012-04-11 19:30 ` Tobias Burnus 2012-04-11 20:44 ` Torvald Riegel 2012-04-13 23:48 ` Dave Korn 2012-04-13 23:37 ` Dave Korn 2012-04-10 17:48 ` DJ Delorie 2012-04-10 19:21 ` Dave Korn 2012-04-10 16:23 ` Xinliang David Li 2012-04-10 16:39 ` Jakub Jelinek 2012-04-10 16:43 ` Gabriel Dos Reis 2012-04-10 16:47 ` Diego Novillo 2012-04-12 19:40 ` Tom Tromey 2012-04-12 19:42 ` Diego Novillo 2012-04-12 19:51 ` Tom Tromey 2012-04-10 17:37 ` Torvald Riegel 2012-04-10 21:39 ` Miles Bader 2012-04-10 22:32 ` Bernd Schmidt 2012-04-10 23:28 ` Eric Botcazou 2012-04-10 23:35 ` Gabriel Dos Reis 2012-04-11 7:49 ` Eric Botcazou 2012-04-11 7:55 ` Gabriel Dos Reis 2012-04-11 8:11 ` Eric Botcazou 2012-04-11 11:41 ` Jeff Law 2012-04-11 7:02 ` Jakub Jelinek 2012-04-11 7:46 ` Gabriel Dos Reis 2012-04-11 7:51 ` Jakub Jelinek 2012-04-11 12:37 ` Bernd Schmidt 2012-04-11 12:47 ` Richard Guenther 2012-04-11 17:10 ` Xinliang David Li 2012-04-11 13:20 ` Gabriel Dos Reis 2012-04-11 13:29 ` Jakub Jelinek 2012-04-11 13:44 ` Gabriel Dos Reis 2012-04-11 14:45 ` David Edelsohn 2012-04-11 17:41 ` Xinliang David Li 2012-04-11 17:08 ` Xinliang David Li 2012-04-11 8:07 ` Eric Botcazou 2012-04-11 9:45 ` Richard Guenther 2012-04-10 17:54 ` Xinliang David Li 2012-04-11 12:44 ` Marek Polacek 2012-04-11 16:49 ` Xinliang David Li 2012-04-11 2:24 ` Lawrence Crowl 2012-04-11 9:43 ` Richard Guenther 2012-04-11 16:47 ` Xinliang David Li 2012-04-11 20:48 ` Paweł Sikora 2012-04-11 22:34 ` Lawrence Crowl 2012-04-12 9:28 ` Chiheng Xu 2012-04-12 10:30 ` Richard Guenther 2012-04-14 1:15 ` Chiheng Xu 2012-04-14 6:30 ` Chiheng Xu 2012-04-14 9:08 ` Robert Dewar 2012-04-14 10:38 ` Chiheng Xu 2012-04-14 11:06 ` Robert Dewar 2012-04-10 16:42 ` Paweł Sikora 2012-04-10 19:23 ` Dave Korn 2012-04-10 20:39 ` Andrew Pinski 2012-04-11 9:27 ` Richard Guenther 2012-04-11 1:01 ` Lawrence Crowl 2012-04-14 3:40 ` Chiheng Xu 2012-04-14 3:48 ` Chiheng Xu 2012-04-15 20:11 ` Chiheng Xu 2012-04-16 7:48 ` Duncan Sands 2012-04-16 9:23 ` Chiheng Xu 2012-04-16 18:53 ` Oleg Endo 2012-04-17 22:03 ` Chiheng Xu 2012-04-18 0:15 ` Oleg Endo 2012-04-10 11:14 ` Richard Guenther 2012-04-10 16:33 ` Xinliang David Li 2012-04-14 2:41 ` Chiheng Xu 2012-04-04 11:22 ` Diego Novillo 2012-04-04 7:07 ` Tristan Gingold 2012-04-04 13:13 ` Ian Lance Taylor 2012-04-04 13:32 ` Tristan Gingold 2012-04-04 14:37 ` Gabriel Dos Reis 2012-04-04 14:52 ` Tristan Gingold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).