Re: Merge C++ conversion into trunk (0/6 - Overview)
On Thu, Aug 23, 2012 at 01:54:38PM -0700, Mike Stump wrote: I think: # Remove the -O2: for historical reasons, unless bootstrapping we prefer # optimizations to be activated explicitly by the toplevel. case $CC in */prev-gcc/xgcc*) ;; *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` ;; esac AC_SUBST(CFLAGS) in configure.ac does this. I think if CXXFLAGS is also so done, we'd gain parity. Can we get this change in? The current state is terribly annoying. Jakub
Re: Merge C++ conversion into trunk (0/6 - Overview)
Il 13/09/2012 10:46, Jakub Jelinek ha scritto: # Remove the -O2: for historical reasons, unless bootstrapping we prefer # optimizations to be activated explicitly by the toplevel. case $CC in */prev-gcc/xgcc*) ;; *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` ;; esac AC_SUBST(CFLAGS) in configure.ac does this. I think if CXXFLAGS is also so done, we'd gain parity. Can we get this change in? The current state is terribly annoying. Yes, please go ahead. Paolo
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Thu, Sep 13, 2012 at 10:53:23AM +0200, Paolo Bonzini wrote: Il 13/09/2012 10:46, Jakub Jelinek ha scritto: # Remove the -O2: for historical reasons, unless bootstrapping we prefer # optimizations to be activated explicitly by the toplevel. case $CC in */prev-gcc/xgcc*) ;; *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` ;; esac AC_SUBST(CFLAGS) in configure.ac does this. I think if CXXFLAGS is also so done, we'd gain parity. Can we get this change in? The current state is terribly annoying. Yes, please go ahead. Here it is, bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested on --disable-bootstrap tree, both by make cc1 inside of gcc subdir (no -O2) and make all-gcc above it (with -O2). Ok for trunk? 2012-09-13 Jakub Jelinek ja...@redhat.com * configure.ac (CXXFLAGS): Remove -O2 when not bootstrapping. * configure: Regenerated. --- gcc/configure.ac.jj 2012-09-13 07:54:41.0 +0200 +++ gcc/configure.ac2012-09-13 14:19:54.016741197 +0200 @@ -296,9 +296,11 @@ AC_SUBST(OUTPUT_OPTION) # optimizations to be activated explicitly by the toplevel. case $CC in */prev-gcc/xgcc*) ;; - *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` ;; + *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` + CXXFLAGS=`echo $CXXFLAGS | sed s/-O[[s0-9]]* *// ` ;; esac AC_SUBST(CFLAGS) +AC_SUBST(CXXFLAGS) # Determine PICFLAG for target gnatlib. GCC_PICFLAG_FOR_TARGET --- gcc/configure.jj2012-09-13 07:54:39.0 +0200 +++ gcc/configure 2012-09-13 14:34:40.429269215 +0200 @@ -4863,10 +4863,12 @@ fi # optimizations to be activated explicitly by the toplevel. case $CC in */prev-gcc/xgcc*) ;; - *) CFLAGS=`echo $CFLAGS | sed s/-O[s0-9]* *// ` ;; + *) CFLAGS=`echo $CFLAGS | sed s/-O[s0-9]* *// ` + CXXFLAGS=`echo $CXXFLAGS | sed s/-O[s0-9]* *// ` ;; esac + # Determine PICFLAG for target gnatlib. @@ -17782,7 +17784,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat conftest.$ac_ext _LT_EOF -#line 17785 configure +#line 17787 configure #include confdefs.h #if HAVE_DLFCN_H @@ -17888,7 +17890,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat conftest.$ac_ext _LT_EOF -#line 17891 configure +#line 17893 configure #include confdefs.h #if HAVE_DLFCN_H Jakub
Re: Merge C++ conversion into trunk (0/6 - Overview)
Il 13/09/2012 17:57, Jakub Jelinek ha scritto: Can we get this change in? The current state is terribly annoying. Yes, please go ahead. Here it is, bootstrapped/regtested on x86_64-linux and i686-linux, additionally tested on --disable-bootstrap tree, both by make cc1 inside of gcc subdir (no -O2) and make all-gcc above it (with -O2). Ok. Paolo
Re: Merge C++ conversion into trunk (0/6 - Overview)
Il 23/08/2012 22:54, Mike Stump ha scritto: # Remove the -O2: for historical reasons, unless bootstrapping we prefer # optimizations to be activated explicitly by the toplevel. case $CC in */prev-gcc/xgcc*) ;; *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` ;; esac AC_SUBST(CFLAGS) in configure.ac does this. I think if CXXFLAGS is also so done, we'd gain parity. Agreed, patch is preapproved. This is not really done to aid debugging though, it is to avoid optimization bugs when compiling stage1. Paolo
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Aug 24, 2012, at 12:24 AM, Paolo Bonzini wrote: Agreed, patch is preapproved. This is not really done to aid debugging though, it is to avoid optimization bugs when compiling stage1. Ah, but building a non-bootstrap compiler from the top-level builds -O2 and when built from the gcc subtree, builds -O0. Ever wonder why? It isn't to avoid code-gen errors in CC. it is to make the developers life easier. I know, so much of gcc's history is lost to time and at times, not handed down to the new kids. The bad bits, just fade away. The useful things, for example, this, will live on, as some of use still know about and use the feature. When it breaks, we complain.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 2012-08-23 16:54 , Mike Stump wrote: On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote: Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. In my gcc/Makefile, I see: CFLAGS = -g CXXFLAGS = -g -O2 Odd. I see: CFLAGS = -g CXXFLAGS = -g in stage1-gcc/ In gcc/ I see both set to -g -O2, of course. I would've noticed -g -O2 in the stage1 build because I am constantly debugging that binary. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Fri, Aug 24, 2012 at 08:30:36AM -0400, Diego Novillo wrote: On 2012-08-23 16:54 , Mike Stump wrote: On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote: Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. In my gcc/Makefile, I see: CFLAGS = -g CXXFLAGS = -g -O2 Odd. I see: CFLAGS = -g CXXFLAGS = -g in stage1-gcc/ In gcc/ I see both set to -g -O2, of course. I would've noticed -g -O2 in the stage1 build because I am constantly debugging that binary. You haven't built your compiler with --disable-bootstrap, so you aren't seeing what Mike is complaining about. Jakub
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 2012-08-24 08:35 , Jakub Jelinek wrote: You haven't built your compiler with --disable-bootstrap, so you aren't seeing what Mike is complaining about. Ah, Mike failed to mention that detail. Mike, it is unlikely that I will be able to work on a fix before I leave. It does not look like a difficult fix in any case. Would you mind preparing a patch? If not, I'll get to it after I return. Thanks. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Aug 24, 2012, at 5:35 AM, Jakub Jelinek wrote: You haven't built your compiler with --disable-bootstrap, so you aren't seeing what Mike is complaining about. Actually, I'm not using disable Just a normal cross compile.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote: Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. In my gcc/Makefile, I see: CFLAGS = -g CXXFLAGS = -g -O2 This makes builds in the gcc directory default to -O2, before they were -O0. -O0 aides in debugging for people that develop the compiler. Do you see this? I think: # Remove the -O2: for historical reasons, unless bootstrapping we prefer # optimizations to be activated explicitly by the toplevel. case $CC in */prev-gcc/xgcc*) ;; *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` ;; esac AC_SUBST(CFLAGS) in configure.ac does this. I think if CXXFLAGS is also so done, we'd gain parity.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Tue, Aug 21, 2012 at 3:31 AM, Lawrence Crowl cr...@google.com wrote: On 8/20/12, H.J. Lu hjl.to...@gmail.com wrote: The C++ merge caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 GCC memory usage is more than doubled from = 3GB to = 10GB. Is this a known issue? The two memory stat reports show no differences. Are you sure you didn't splice in the wrong report? Well, easy things such as a messed up hashtab conversion (no freeing) or vec conversion (no freeing) can cause this, or even the gengtype change causing GC issues (which is why those should have been different revisions). Richard. -- Lawrence Crowl
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Tue, Aug 14, 2012 at 11:59 AM, Diego Novillo dnovi...@google.com wrote: On 12-08-14 09:48 , Diego Novillo wrote: This merge touches several files, so I'm thinking that the best time is going to be on Thu 16/Aug around 2:00 GMT. So, the fixes I needed from Lawrence are already in so we can proceed with the merge. I'll commit the merge tonight at ~2:00 GMT. After the merge is in, I will send an announcement and request major branch merges to wait for another 24 hrs to allow testers the chance to pick up this merge. The C++ merge caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 GCC memory usage is more than doubled from = 3GB to = 10GB. Is this a known issue? -- H.J.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 8/20/12, H.J. Lu hjl.to...@gmail.com wrote: The C++ merge caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 GCC memory usage is more than doubled from = 3GB to = 10GB. Is this a known issue? The two memory stat reports show no differences. Are you sure you didn't splice in the wrong report? -- Lawrence Crowl
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Mon, Aug 20, 2012 at 6:31 PM, Lawrence Crowl cr...@google.com wrote: On 8/20/12, H.J. Lu hjl.to...@gmail.com wrote: The C++ merge caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 GCC memory usage is more than doubled from = 3GB to = 10GB. Is this a known issue? The two memory stat reports show no differences. Are you sure you didn't splice in the wrong report? Those are outputs from -fmem-report. I am not sure how useful they are for this bug. -- H.J.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote: On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote: Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes: Tom I asked Keith to resurrect his patch for this. [snip] I hope this will be acceptable all around. OK, that sounds reasonable. I have committed a patch which should allow you to do this and closed c++/13356. If there are any further problems/issues, please let me know. We've re-purposed an old, unused option, check type. This option does absolutely nothing in older versions of gdb, so setting it unconditionally is safe for all recent versions of gdb: set check type off. Keith
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Fri, Aug 17, 2012 at 10:45 AM, Keith Seitz kei...@redhat.com wrote: On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote: On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote: Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes: Tom I asked Keith to resurrect his patch for this. [snip] I hope this will be acceptable all around. OK, that sounds reasonable. I have committed a patch which should allow you to do this and closed c++/13356. If there are any further problems/issues, please let me know. We've re-purposed an old, unused option, check type. This option does absolutely nothing in older versions of gdb, so setting it unconditionally is safe for all recent versions of gdb: set check type off. Shouldn't it be added to GCC .gdbinit? -- H.J.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 12-08-15 07:59 , Richard Guenther wrote: (gdb) call debug_tree (*expr_p) integer_cst 0x7695d7c0 type integer_type 0x767fa5e8 int constant 9 (gdb) call debug_tree (0x767fa5e8) Cannot resolve function debug_tree to any overloaded instance Yeah, in the absence of overloads this is annoying. Happens with 0, too. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Wed, 15 Aug 2012, Diego Novillo wrote: On 12-08-15 07:59 , Richard Guenther wrote: (gdb) call debug_tree (*expr_p) integer_cst 0x7695d7c0 type integer_type 0x767fa5e8 int constant 9 (gdb) call debug_tree (0x767fa5e8) Cannot resolve function debug_tree to any overloaded instance Yeah, in the absence of overloads this is annoying. Happens with 0, too. 0 is fixed if you have recent enough gdb. (gdb) call debug_tree (0) as 0 is a null pointer constant. Richard.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 12-08-15 08:18 , Richard Guenther wrote: 0 is fixed if you have recent enough gdb. (gdb) call debug_tree (0) as 0 is a null pointer constant. Oh, cool. Progress. GDB folks, would it be hard to figure out that there is a single variant of the called function and trust the user that they are passing the right pointer value? Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Aug 15, 2012, at 4:59 AM, Richard Guenther wrote: and debugging becomes a nightmare (hello gdb people!) (gdb) call debug_tree (0x767fa5e8) Cannot resolve function debug_tree to any overloaded instance Inquiring minds want to know if: macro define debug_tree(A) ((tree)A) makes the above work if you put it into gdbinit.in? If yes, then, I think for now we should add such lines for every non-overloaded function, I too like using hex constants from dumps. Oh, or, maybe we just add a debug_tree(long) overload just to satisfy gdb.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Wed, 15 Aug 2012 14:23:37 +0200, Diego Novillo wrote: GDB folks, would it be hard to figure out that there is a single variant of the called function and trust the user that they are passing the right pointer value? It is a needless violation of C++ resolving rules. There are various easy way how to get it working (in .gdbinit or cc1-gdb.gdb define GDB function, define macro in GDB, use GDB python pretty printer instead (possibly even calling GCC inferior function) etc.). While I did not post such patch yet I would prefer to even forbid by default expressions like (gdb) print *0x1234567 and enforce (gdb) print *(int *)0x1234567 instead as the former syntax confuses people (as commonly seen on IRC), the same applies to calling functions without full debuginfo (they should require an explicit cast in GDB) etc. Regards, Jan
Re: Merge C++ conversion into trunk (0/6 - Overview)
Hi, On Wed, 15 Aug 2012, Jan Kratochvil wrote: It is a needless violation of C++ resolving rules. It's not needless as the examples here show. gdb is about helping people debug their stuff, not about language lawyering. There are various easy way how to get it working (in .gdbinit or cc1-gdb.gdb define GDB function, define macro in GDB, use GDB python pretty printer instead (possibly even calling GCC inferior function) We should define gdb macros for every not-overloaded function (which are _all_ GCC functions currently)? Doesn't scale. Ciao, Michael.
Re: Merge C++ conversion into trunk (0/6 - Overview)
Hi, On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote: On Wed, 15 Aug 2012, Jan Kratochvil wrote: It's not needless as the examples here show. gdb is about helping people debug their stuff, not about language lawyering. In such case there should be a GDB setting for it as at least from my opinion it complicates the debugging. Then there may be different opinions what should be the default. Thanks, Jan
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 12-08-15 11:44 , Michael Matz wrote: Hi, On Wed, 15 Aug 2012, Jan Kratochvil wrote: It is a needless violation of C++ resolving rules. It's not needless as the examples here show. gdb is about helping people debug their stuff, not about language lawyering. Agreed. If I'm passing a numeric pointer constant, I'm already past the bleeding edge. I don't want gdb to get in the way. If the inferior call crashes, I get to keep both pieces. Thanks. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Wed, Aug 15, 2012 at 05:49:34PM +0200, Jan Kratochvil wrote: On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote: On Wed, 15 Aug 2012, Jan Kratochvil wrote: It's not needless as the examples here show. gdb is about helping people debug their stuff, not about language lawyering. In such case there should be a GDB setting for it as at least from my opinion it complicates the debugging. Then there may be different opinions what should be the default. That would be fine for gcc development purposes. We could switch that mode on at the end of gcc .gdbinit . Jakub
Re: Merge C++ conversion into trunk (0/6 - Overview)
Diego == Diego Novillo dnovi...@google.com writes: Diego GDB folks, would it be hard to figure out that there is a single Diego variant of the called function and trust the user that they are Diego passing the right pointer value? I asked Keith to resurrect his patch for this. Tom
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Wed, Aug 15, 2012 at 12:53 PM, Tom Tromey tro...@redhat.com wrote: Diego == Diego Novillo dnovi...@google.com writes: Diego GDB folks, would it be hard to figure out that there is a single Diego variant of the called function and trust the user that they are Diego passing the right pointer value? I asked Keith to resurrect his patch for this. Since people are concerned about typing rules, would it be an option for GDB to allow people to input pointer literals with the p suffix (or 0p prefix instead of 0x)? -- Gaby
Re: Merge C++ conversion into trunk (0/6 - Overview)
Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes: Tom I asked Keith to resurrect his patch for this. Gaby Since people are concerned about typing rules, would it Gaby be an option for GDB to allow people to input pointer Gaby literals with the p suffix (or 0p prefix instead of 0x)? I think on the whole I'd rather have one extension instead of two. It seems to me that the above would still require extensions in the overloading code, to deal with conversions from void*; or perhaps some magic pointer type. What I think Keith is going to do is take his patch, change it so that int-pointer conversions (if the int != 0) are given a different badness from other conversions (meaning that, in theory, this should only be chosen as a last resort, and shouldn't interfere with ordinary uses), and finally add a parameter so that the feature can be disabled. I hope this will be acceptable all around. Tom
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey tro...@redhat.com wrote: Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes: Tom I asked Keith to resurrect his patch for this. Gaby Since people are concerned about typing rules, would it Gaby be an option for GDB to allow people to input pointer Gaby literals with the p suffix (or 0p prefix instead of 0x)? I think on the whole I'd rather have one extension instead of two. That is a fair point :-) It seems to me that the above would still require extensions in the overloading code, to deal with conversions from void*; or perhaps some magic pointer type. What I think Keith is going to do is take his patch, change it so that int-pointer conversions (if the int != 0) are given a different badness from other conversions (meaning that, in theory, this should only be chosen as a last resort, and shouldn't interfere with ordinary uses), and finally add a parameter so that the feature can be disabled. I hope this will be acceptable all around. OK, that sounds reasonable. Thanks! -- Gaby
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 08/15/2012 06:00 PM, Diego Novillo wrote: On the switch to C++ as the build language for GCC ... Here are my results: 0:30 UTC - using C as the initial build language: http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01329.html and: 18:40 UTC - using C++ as the initial build language: http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01408.html both for x86_64-unknown-linux-gnu native (note: --with-build-config=bootstrap-lto). As far as I can, little difference. Congratulations, Diego and all the others who worked on this transition. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 12-08-14 09:48 , Diego Novillo wrote: This merge touches several files, so I'm thinking that the best time is going to be on Thu 16/Aug around 2:00 GMT. So, the fixes I needed from Lawrence are already in so we can proceed with the merge. I'll commit the merge tonight at ~2:00 GMT. After the merge is in, I will send an announcement and request major branch merges to wait for another 24 hrs to allow testers the chance to pick up this merge. Thanks. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo dnovi...@google.com wrote: I will be sending 6 patches that implement all the changes we have been making on the cxx-conversion branch. As described in http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches change the default bootstrap process so that stage 1 always builds with a C++ compiler. Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. I have split the merge in 6 main patches. I will send these patches to the respective maintainers and gcc-patches. Please remember that the patches conform to the new C++ coding guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions): 1- Configuration changes. 2- Re-write of VEC. 3- Re-write of gengtype to support C++ templates and user-provided marking functions. 4- New hash table class. 5- Re-write double_int. 6- Implement tree macros as inline functions so they can be called from gdb. As discussed before, several of these patches do not fully change the call sites to use the new APIs. We will do this change once the branch has been merged into trunk. Otherwise, the branch becomes a maintenance nightmare (despite not having changed many caller sites we were already starting to run into maintenance problems). As I understand only 1. to 3. were kind-of required for the merge, all other changes are a bonus at this time and should be delayed IMHO (thus not merged with this batch). I also understand that you will, quickly after merging 1. to 3. convert all VEC users and remove the old interface. This should be done before any of 4. - 6. is merged as generally we don't want the half-converted to persist, nor have multiple such half-conversions at the same time. I also understand that the merge of 1. to 3. will be followed by the promised gengtype improvements and re-organizations. Thus, please to the first C++ things very well. Thanks, Richard. For those who would like to build the conversion, you can either checkout the branch from SVN (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged trunk I have in the git repo (branch dnovillo/cxx-conversion). The bootstrap changes have already been tested on a wide range of targets (http://gcc.gnu.org/wiki/CppBuildStatus). Additionally, I have tested the merged trunk on: x86_64-unknown-linux-gnu, mips64el-unknown-linux-gnu, powerpc64-unknown-linux-gnu, i686-pc-linux-gnu, and ia64-unknown-linux-gnu. Thanks. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 12-08-13 05:37 , Richard Guenther wrote: On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo dnovi...@google.com wrote: I will be sending 6 patches that implement all the changes we have been making on the cxx-conversion branch. As described in http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches change the default bootstrap process so that stage 1 always builds with a C++ compiler. Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. I have split the merge in 6 main patches. I will send these patches to the respective maintainers and gcc-patches. Please remember that the patches conform to the new C++ coding guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions): 1- Configuration changes. 2- Re-write of VEC. 3- Re-write of gengtype to support C++ templates and user-provided marking functions. 4- New hash table class. 5- Re-write double_int. 6- Implement tree macros as inline functions so they can be called from gdb. As discussed before, several of these patches do not fully change the call sites to use the new APIs. We will do this change once the branch has been merged into trunk. Otherwise, the branch becomes a maintenance nightmare (despite not having changed many caller sites we were already starting to run into maintenance problems). As I understand only 1. to 3. were kind-of required for the merge, all other changes are a bonus at this time and should be delayed IMHO (thus not merged with this batch). Both #4 and #5 have the same issues as #3 (VEC). What remains to be done is update a whole swath of user code. This is hard to maintain in the branch and needs to be done during stage 1. The change in #6 is similarly ready, so delaying it makes no sense. What I can do is merge #1-#3 as one rev and merge the others as 3 separate revisions. I also understand that you will, quickly after merging 1. to 3. convert all VEC users and remove the old interface. This should be done before any of 4. - 6. is merged as generally we don't want the half-converted to persist, nor have multiple such half-conversions at the same time. Yes, there will be no half conversions. We are committed to continue making changes in this area. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Sun, 12 Aug 2012, Diego Novillo wrote: For those who would like to build the conversion, you can either checkout the branch from SVN (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged trunk I have in the git repo (branch dnovillo/cxx-conversion). The bootstrap changes have already been tested on a wide range of targets (http://gcc.gnu.org/wiki/CppBuildStatus). Hello, as a matter of policy, is it required that non-gcc compilers can be used to initiate the bootstrap? In the table, clang seems to be the only other compiler that managed. IBM and Oracle both fail (the comment is not clear, but I think 12.3 also fails, just not exactly in the same way), and HP and Intel (to mention just a few) are not listed. -- Marc Glisse PS: I never know if it is better to trim Cc: lists in answers or let them grow...
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo dnovi...@google.com wrote: I will be sending 6 patches that implement all the changes we have been making on the cxx-conversion branch. As described in http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches change the default bootstrap process so that stage 1 always builds with a C++ compiler. Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. I have split the merge in 6 main patches. I will send these patches to the respective maintainers and gcc-patches. Please remember that the patches conform to the new C++ coding guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions): 1- Configuration changes. 2- Re-write of VEC. 3- Re-write of gengtype to support C++ templates and user-provided marking functions. 4- New hash table class. 5- Re-write double_int. 6- Implement tree macros as inline functions so they can be called from gdb. As discussed before, several of these patches do not fully change the call sites to use the new APIs. We will do this change once the branch has been merged into trunk. Otherwise, the branch becomes a maintenance nightmare (despite not having changed many caller sites we were already starting to run into maintenance problems). For those who would like to build the conversion, you can either checkout the branch from SVN (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged trunk I have in the git repo (branch dnovillo/cxx-conversion). dnovillo/cxx-conversion git branch failed to bootstrap on Fedora 17 x86-64 when configured with --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go I got /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c: In function \u2018tree_node* objc_build_constructor(tree, vec_tconstructor_elt_d*)\u2019: /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c:3212:44: error: base operand of \u2018-\u2019 has non-pointer type \u2018constructor_elt_d\u2019 if (!VEC_index (constructor_elt, elts, 0)-index) -- H.J.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo dnovi...@google.com wrote: I will be sending 6 patches that implement all the changes we have been making on the cxx-conversion branch. As described in http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches change the default bootstrap process so that stage 1 always builds with a C++ compiler. Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. I have split the merge in 6 main patches. I will send these patches to the respective maintainers and gcc-patches. Please remember that the patches conform to the new C++ coding guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions): 1- Configuration changes. 2- Re-write of VEC. 3- Re-write of gengtype to support C++ templates and user-provided marking functions. 4- New hash table class. 5- Re-write double_int. 6- Implement tree macros as inline functions so they can be called from gdb. As discussed before, several of these patches do not fully change the call sites to use the new APIs. We will do this change once the branch has been merged into trunk. Otherwise, the branch becomes a maintenance nightmare (despite not having changed many caller sites we were already starting to run into maintenance problems). For those who would like to build the conversion, you can either checkout the branch from SVN (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged trunk I have in the git repo (branch dnovillo/cxx-conversion). dnovillo/cxx-conversion git branch failed to bootstrap on Fedora 17 x86-64 when configured with --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go I got /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c: In function \u2018tree_node* objc_build_constructor(tree, vec_tconstructor_elt_d*)\u2019: /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c:3212:44: error: base operand of \u2018-\u2019 has non-pointer type \u2018constructor_elt_d\u2019 if (!VEC_index (constructor_elt, elts, 0)-index) This patch fixes the error: diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c index 5c924bf..caa16c7 100644 --- a/gcc/objc/objc-act.c +++ b/gcc/objc/objc-act.c @@ -3209,7 +3209,7 @@ objc_build_constructor (tree type, VEC(constructor_elt,gc) *elts) #ifdef OBJCPLUS /* Adjust for impedance mismatch. We should figure out how to build CONSTRUCTORs that consistently please both the C and C++ gods. */ - if (!VEC_index (constructor_elt, elts, 0)-index) + if (!VEC_index (constructor_elt, elts, 0).index) TREE_TYPE (constructor) = init_list_type_node; #endif -- H.J.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 12-08-12 18:38 , H.J. Lu wrote: On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo dnovi...@google.com wrote: I will be sending 6 patches that implement all the changes we have been making on the cxx-conversion branch. As described in http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches change the default bootstrap process so that stage 1 always builds with a C++ compiler. Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. I have split the merge in 6 main patches. I will send these patches to the respective maintainers and gcc-patches. Please remember that the patches conform to the new C++ coding guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions): 1- Configuration changes. 2- Re-write of VEC. 3- Re-write of gengtype to support C++ templates and user-provided marking functions. 4- New hash table class. 5- Re-write double_int. 6- Implement tree macros as inline functions so they can be called from gdb. As discussed before, several of these patches do not fully change the call sites to use the new APIs. We will do this change once the branch has been merged into trunk. Otherwise, the branch becomes a maintenance nightmare (despite not having changed many caller sites we were already starting to run into maintenance problems). For those who would like to build the conversion, you can either checkout the branch from SVN (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged trunk I have in the git repo (branch dnovillo/cxx-conversion). dnovillo/cxx-conversion git branch failed to bootstrap on Fedora 17 x86-64 when configured with --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go I got /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c: In function \u2018tree_node* objc_build_constructor(tree, vec_tconstructor_elt_d*)\u2019: /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c:3212:44: error: base operand of \u2018-\u2019 has non-pointer type \u2018constructor_elt_d\u2019 if (!VEC_index (constructor_elt, elts, 0)-index) This patch fixes the error: diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c index 5c924bf..caa16c7 100644 --- a/gcc/objc/objc-act.c +++ b/gcc/objc/objc-act.c @@ -3209,7 +3209,7 @@ objc_build_constructor (tree type, VEC(constructor_elt,gc) *elts) #ifdef OBJCPLUS /* Adjust for impedance mismatch. We should figure out how to build CONSTRUCTORs that consistently please both the C and C++ gods. */ - if (!VEC_index (constructor_elt, elts, 0)-index) + if (!VEC_index (constructor_elt, elts, 0).index) TREE_TYPE (constructor) = init_list_type_node; #endif Thanks. Missed this because --enable-languages=all does not enable obj-c++. Please commit to the branch. I'll update the git image. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On 12-08-12 16:57 , Marc Glisse wrote: other compiler that managed. IBM and Oracle both fail (the comment is not clear, but I think 12.3 also fails, just not exactly in the same way), and HP and Intel (to mention just a few) are not listed. We should fix/workaround failing host C++ compilers similarly to how we deal with host C compilers. If you have access to any of the compilers you mention, could you try building the branch? Thanks. Diego.
Re: Merge C++ conversion into trunk (0/6 - Overview)
On Sun, Aug 12, 2012 at 5:27 PM, Diego Novillo dnovi...@google.com wrote: On 12-08-12 18:38 , H.J. Lu wrote: On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo dnovi...@google.com wrote: I will be sending 6 patches that implement all the changes we have been making on the cxx-conversion branch. As described in http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches change the default bootstrap process so that stage 1 always builds with a C++ compiler. Other than the bootstrap change, the patches make no functional changes to the compiler. Everything should build as it does now in trunk. I have split the merge in 6 main patches. I will send these patches to the respective maintainers and gcc-patches. Please remember that the patches conform to the new C++ coding guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions): 1- Configuration changes. 2- Re-write of VEC. 3- Re-write of gengtype to support C++ templates and user-provided marking functions. 4- New hash table class. 5- Re-write double_int. 6- Implement tree macros as inline functions so they can be called from gdb. As discussed before, several of these patches do not fully change the call sites to use the new APIs. We will do this change once the branch has been merged into trunk. Otherwise, the branch becomes a maintenance nightmare (despite not having changed many caller sites we were already starting to run into maintenance problems). For those who would like to build the conversion, you can either checkout the branch from SVN (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged trunk I have in the git repo (branch dnovillo/cxx-conversion). dnovillo/cxx-conversion git branch failed to bootstrap on Fedora 17 x86-64 when configured with --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go I got /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c: In function \u2018tree_node* objc_build_constructor(tree, vec_tconstructor_elt_d*)\u2019: /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c:3212:44: error: base operand of \u2018-\u2019 has non-pointer type \u2018constructor_elt_d\u2019 if (!VEC_index (constructor_elt, elts, 0)-index) This patch fixes the error: diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c index 5c924bf..caa16c7 100644 --- a/gcc/objc/objc-act.c +++ b/gcc/objc/objc-act.c @@ -3209,7 +3209,7 @@ objc_build_constructor (tree type, VEC(constructor_elt,gc) *elts) #ifdef OBJCPLUS /* Adjust for impedance mismatch. We should figure out how to build CONSTRUCTORs that consistently please both the C and C++ gods. */ - if (!VEC_index (constructor_elt, elts, 0)-index) + if (!VEC_index (constructor_elt, elts, 0).index) TREE_TYPE (constructor) = init_list_type_node; #endif Thanks. Missed this because --enable-languages=all does not enable obj-c++. Please commit to the branch. I'll update the git image. I checked it into cxx-conversion branch. -- H.J.
