gcc-in-cxx branch created

gcc-in-cxx branch created

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

As I promised at the summit today, I have created the branch
gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
better to avoid possible meta-characters).  The goal of this branch is
to develop a version of gcc which is compiled with C++.  Here are my
presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf .

I have not yet committed any patches to the branch--at present it is
just a copy of the trunk.  I will start committing patches soon, and
anybody else may submit patches as well.  The branch will follow the
usual gcc maintainership rules, except that any non-algorithmic
maintainer may additionally approve or commit patches which permit
compilation with C++.

I have committed the appended patch to htdocs/svn.html.

Ian


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Document gcc-in-cxx branch --]
[-- Type: text/x-patch, Size: 868 bytes --]

Index: svn.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.86
diff -u -r1.86 svn.html
--- svn.html	12 Jun 2008 14:22:37 -0000	1.86
+++ svn.html	18 Jun 2008 06:00:13 -0000
@@ -410,6 +410,14 @@
   <code>[function-specific]</code> in the subject line.
   The branch is maintained by Michael Meissner.</dd>
 
+  <dt>gcc-in-cxx</dt>
+  <dd>This branch is for converting gcc to be written in C++.  Patches
+  should be marked with the tag <code>[gcc-in-cxx]</code> in the
+  subject line.  This branch operates under the general gcc
+  maintainership rules, except that any non-algorithmic maintainer is
+  additionally permitted to approve changes which permit compilation
+  with C++.  The branch is maintained by Ian Lance Taylor.</dd>
+
 </dl>
 
 <h4>Architecture-specific</h4>

Re: gcc-in-cxx branch created

[Doug Gregor]

On Wed, Jun 18, 2008 at 2:01 AM, Ian Lance Taylor <iant@google.com> wrote:
> As I promised at the summit today, I have created the branch
> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
> better to avoid possible meta-characters).  The goal of this branch is
> to develop a version of gcc which is compiled with C++.  Here are my
> presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf .

I, personally, think this would be a great step forward from a
maintainability perspective, especially if we use those C++ features
that can help eliminate many of the macros we currently have in GCC.

The first step seems to be to make sure that GCC compiles as C++ now
(I know there's been work in this direction), and for us to make sure
that this property is maintained in the mainline compiler. The C++
front end would be a good place to start moving toward C++.

  - Doug

Re: gcc-in-cxx branch created

[Diego Novillo]

On 6/18/08 2:01 AM, Ian Lance Taylor wrote:
> As I promised at the summit today, I have created the branch
> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
> better to avoid possible meta-characters).  The goal of this branch is
> to develop a version of gcc which is compiled with C++.  Here are my
> presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf .

Will this evolve into a branch to switch GCC's implementation language 
to C++.  Or are you thinking about a separate branch for this?


Diego.

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

[ I dropped gcc-patches from this reply. ]

Diego Novillo <dnovillo@google.com> writes:

> On 6/18/08 2:01 AM, Ian Lance Taylor wrote:
>> As I promised at the summit today, I have created the branch
>> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
>> better to avoid possible meta-characters).  The goal of this branch is
>> to develop a version of gcc which is compiled with C++.  Here are my
>> presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf .
>
> Will this evolve into a branch to switch GCC's implementation language
> to C++.  Or are you thinking about a separate branch for this?

Yes, that is the goal of this branch: to switch GCC's implementation
language.  My hope is to keep this branch fairly close to mainline,
except that gcc code will be compiled with C++.  My hope is then to
merge the branch back into mainline, at which point gcc will be
written in C++.

Questions like exactly which gcc code will be compiled with C++ on the
branch remain open, but it will certainly include everything in
libbackend.a.

Ian

Re: gcc-in-cxx branch created

[Thomas Neumann]

Hi,

On 2008-06-17 23:01, Ian Lance Taylor wrote:
> As I promised at the summit today, I have created the branch
> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
> better to avoid possible meta-characters).  The goal of this branch is
> to develop a version of gcc which is compiled with C++.
I have a patch that allows to build a working gcc (--enable-languages=c
only) with a C++ compiler. Are you interested in it?
I tried to get parts of it into mainline but as my patches were mostly
ignored I stopped tracking mainline, so it is a bit bitrotten. If you
are interested I could try to bring it back into shape for the current
mainline.

One thing that I noticed is that even new code frequently breaks C++
compatibility. People are very fond of using C++ keywords as variable
names...

Thomas

Re: gcc-in-cxx branch created

[Joseph S. Myers]

wwwdocs isn't branched, but there should be a version of 
codingconventions.html with the conventions being followed for the use of 
C++ on the branch.  (Parts of the libstdc++ coding style may be relevant.)

I think a more conservative approach is needed to being buildable with a 
range of versions than making sure version N is buildable with N-1; I 
suggest choosing a GCC version between three and five years old and saying 
that code must be in the intersection of ISO C++98 and the parts of C++ 
supported by that version (and testing bootstrap with a non-GNU compiler, 
as well as with the GCC version chosen, before any merge to trunk).  For 
comparison, 2.95 is the current minimum version for building the non-C, 
non-Ada front ends (when building a cross compiler), while 3.4 is required 
for building Ada, and all non-Ada front ends can be bootstrapped starting 
from a non-GNU C compiler.  The versions chosen should of course go in 
gcc/doc/install.texi on the branch.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Wed, 18 Jun 2008, Doug Gregor wrote:

> On Wed, Jun 18, 2008 at 2:01 AM, Ian Lance Taylor <iant@google.com> wrote:
> > As I promised at the summit today, I have created the branch
> > gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
> > better to avoid possible meta-characters).  The goal of this branch is
> > to develop a version of gcc which is compiled with C++.  Here are my
> > presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf .
>
> I, personally, think this would be a great step forward from a
> maintainability perspective, especially if we use those C++ features
> that can help eliminate many of the macros we currently have in GCC.

Agreed, this is a terrific idea.

>
> The first step seems to be to make sure that GCC compiles as C++ now
> (I know there's been work in this direction), and for us to make sure
> that this property is maintained in the mainline compiler. The C++
> front end would be a good place to start moving toward C++.
>   - Doug

I read through your slides and I'm interested in contributing.  I didn't
see the presentation itself so I don't know if this suggestion is
redundant.  However I believe some work could be done (maybe even on
mainline) to activate -Wc++-compat during bootstrap as a warning only,
(not an error).  E.g.:

	#pragma GCC diagnostic warning "-Wc++-compat"

This would help clean up some of the easy stuff and make the branch diffs
much smaller.

We could also extend -Wc++-compat to warn about more things, using C++
reserved keywords like "class" in C comes to mind.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:

> [...] I believe some work could be done (maybe even on mainline) to
> activate -Wc++-compat during bootstrap as a warning only, (not an
> error).  E.g.:
>
> 	#pragma GCC diagnostic warning "-Wc++-compat"
>
> This would help clean up some of the easy stuff and make the branch diffs
> much smaller.

Some stats, I ran a quick make including the above #pragma in system.h, I
get 1089 new warnings.  Running this grep pipe on the output file:

	grep 'request for implicit conversion' output|sed 's%[^/]*\.[chl]:.*%%'|sort |uniq -c

yields:

      6
    754 ../../egcc-SVN20080619/gcc/
    231 ../../egcc-SVN20080619/gcc/fortran/
     72 ../../egcc-SVN20080619/gcc/java/
     26 ../../egcc-SVN20080619/gcc/objc/

The blank 6 are from insn-automata.c, which has no path prefix and gets
nulled out by my shellism.  There are no warnings from the C++ dir because
someone already cleaned it up and added -Wc++-compat, likewise for
libiberty.  (Who did that, Gaby?)

These are mechanical and can be fixed with simple casts.  Again, IMHO
these non-controversial patches should go straight into mainline.
Once done we can -Werror this warning and avoid regressions.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

First, many thanks to Ian for stepping forward to make this happen.

On Thu, Jun 19, 2008 at 1:55 AM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:
>
>> [...] I believe some work could be done (maybe even on mainline) to
>> activate -Wc++-compat during bootstrap as a warning only, (not an
>> error).  E.g.:
>>
>>       #pragma GCC diagnostic warning "-Wc++-compat"
>>
>> This would help clean up some of the easy stuff and make the branch diffs
>> much smaller.
>
> Some stats, I ran a quick make including the above #pragma in system.h, I
> get 1089 new warnings.  Running this grep pipe on the output file:
>
>        grep 'request for implicit conversion' output|sed 's%[^/]*\.[chl]:.*%%'|sort |uniq -c
>
> yields:
>
>      6
>    754 ../../egcc-SVN20080619/gcc/
>    231 ../../egcc-SVN20080619/gcc/fortran/
>     72 ../../egcc-SVN20080619/gcc/java/
>     26 ../../egcc-SVN20080619/gcc/objc/
>
> The blank 6 are from insn-automata.c, which has no path prefix and gets
> nulled out by my shellism.  There are no warnings from the C++ dir because
> someone already cleaned it up and added -Wc++-compat, likewise for
> libiberty.  (Who did that, Gaby?)

Yes, I already did the work for cp/.
I also got help from a GCC contributor (whose name I temporariy
forgot) and Thomas
on some C files.

Main offenders (last time I checked) seem be to
  (1) middle end and back end files who play `enum inheritance' tricks.
  (2) use of C++ keywords as variable names.
  (3) implicit conversion from void* to T* -- but we should have ver
few of those
      now, because I did eliminate those I was aware of
  (4) minor: some differences in `const' semantics.

-Wc++-compat needs to be augmented to check for C++ keywords
(a deficiency in current implementation).

I'm `on the road' and my laptop is a `windows only' box.

>
> These are mechanical and can be fixed with simple casts.  Again, IMHO
> these non-controversial patches should go straight into mainline.
> Once done we can -Werror this warning and avoid regressions.

Strongly agree.  Would you mind submitting the patch for activation of
-Wc++-compat?

There was also a suggestion to specificy a version for C++.  I believe
C++98 should
be enough for our purposes -- GCC-3.4.x should be good enough.

-- Gaby

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Gabriel Dos Reis wrote:

> Main offenders (last time I checked) seem be to
>   (1) middle end and back end files who play `enum inheritance' tricks.
>   (2) use of C++ keywords as variable names.
>   (3) implicit conversion from void* to T* -- but we should have ver
> few of those
>       now, because I did eliminate those I was aware of

Um, no.  I see 1089 warnings of type #3. :-/


>   (4) minor: some differences in `const' semantics.
>
> -Wc++-compat needs to be augmented to check for C++ keywords
> (a deficiency in current implementation).

Yes, PR21759.  Will you be able to work on that?  (Or at least, list in
the PR what the reserved keywords are in case someone else wants to?)


>
> I'm `on the road' and my laptop is a `windows only' box.
>
> >
> > These are mechanical and can be fixed with simple casts.  Again, IMHO
> > these non-controversial patches should go straight into mainline.
> > Once done we can -Werror this warning and avoid regressions.
>
> Strongly agree.  Would you mind submitting the patch for activation of
> -Wc++-compat?

Done.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Thu, Jun 19, 2008 at 3:10 AM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> On Thu, 19 Jun 2008, Gabriel Dos Reis wrote:
>
>> Main offenders (last time I checked) seem be to
>>   (1) middle end and back end files who play `enum inheritance' tricks.
>>   (2) use of C++ keywords as variable names.
>>   (3) implicit conversion from void* to T* -- but we should have ver
>> few of those
>>       now, because I did eliminate those I was aware of
>
> Um, no.  I see 1089 warnings of type #3. :-/

gasp :-(

>
>
>>   (4) minor: some differences in `const' semantics.
>>
>> -Wc++-compat needs to be augmented to check for C++ keywords
>> (a deficiency in current implementation).
>
> Yes, PR21759.  Will you be able to work on that?  (Or at least, list in
> the PR what the reserved keywords are in case someone else wants to?)

Yes, I'll work on it.

>> I'm `on the road' and my laptop is a `windows only' box.
>>
>> >
>> > These are mechanical and can be fixed with simple casts.  Again, IMHO
>> > these non-controversial patches should go straight into mainline.
>> > Once done we can -Werror this warning and avoid regressions.
>>
>> Strongly agree.  Would you mind submitting the patch for activation of
>> -Wc++-compat?
>
> Done.

Many thanks.

-- Gaby

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Wed, Jun 18, 2008 at 1:01 AM, Ian Lance Taylor <iant@google.com> wrote:
> As I promised at the summit today, I have created the branch
> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
> better to avoid possible meta-characters).  The goal of this branch is
> to develop a version of gcc which is compiled with C++.  Here are my
> presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf .

Excellent slides.  Many thanks for doing this.

>
> I have not yet committed any patches to the branch--at present it is
> just a copy of the trunk.  I will start committing patches soon, and
> anybody else may submit patches as well.  The branch will follow the
> usual gcc maintainership rules, except that any non-algorithmic
> maintainer may additionally approve or commit patches which permit
> compilation with C++.

I have a question:  I suspect that in concreteness you would prefer declarations
in GCC headers have a C++ linkage, as opposed to C linkage -- except where
for interoperability  with common runtime systems, we want the
declarations to have
C linkage (e.g. in libgcc for example).  Am I correct?
The reason I'm asking is that a fresh build o gcc-in-cxx dies on my machine with
complains that `program' has conflicting declarations: once in
libcpp.h as having
C++ linkage, once in toplev.h with a C declaration.  It is the
tradition in modern
C++ to avoid having many `sources' for the same declaration.

-- Gaby

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

"Kaveh R. GHAZI" <ghazi@caip.rutgers.edu> writes:

> I read through your slides and I'm interested in contributing.  I didn't
> see the presentation itself so I don't know if this suggestion is
> redundant.  However I believe some work could be done (maybe even on
> mainline) to activate -Wc++-compat during bootstrap as a warning only,
> (not an error).  E.g.:
>
> 	#pragma GCC diagnostic warning "-Wc++-compat"
>
> This would help clean up some of the easy stuff and make the branch diffs
> much smaller.
>
> We could also extend -Wc++-compat to warn about more things, using C++
> reserved keywords like "class" in C comes to mind.

Yes, I agree that both steps would be quite useful.  There is already
some support in the gcc configure system and Makefile to do this;
search for CXX_COMPAT_WARN in gcc/Makefile.in.  Adding
$(CXX_COMPAT_WARN) to $(GCC_WARN_CFLAGS) will make -Wc++-compat be
used when the build compiler supports it.

> Some stats, I ran a quick make including the above #pragma in system.h, I
> get 1089 new warnings.

Yes.  I am testing a mainline patch to clean up the tree codes now
(now that we've gone to 16 bits for tree codes, there is no need to
force each frontend to use a separate set of codes).

> These are mechanical and can be fixed with simple casts.  Again, IMHO
> these non-controversial patches should go straight into mainline.
> Once done we can -Werror this warning and avoid regressions.

Yes, I agree.

Ian

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

[ Dropping gcc-patches. ]

"Gabriel Dos Reis" <gdr@integrable-solutions.net> writes:

>> I have not yet committed any patches to the branch--at present it is
>> just a copy of the trunk.  I will start committing patches soon, and
>> anybody else may submit patches as well.  The branch will follow the
>> usual gcc maintainership rules, except that any non-algorithmic
>> maintainer may additionally approve or commit patches which permit
>> compilation with C++.
>
> I have a question:  I suspect that in concreteness you would prefer declarations
> in GCC headers have a C++ linkage, as opposed to C linkage -- except where
> for interoperability  with common runtime systems, we want the
> declarations to have
> C linkage (e.g. in libgcc for example).  Am I correct?

Yes, I think that makes the most sense.

> The reason I'm asking is that a fresh build o gcc-in-cxx dies on my machine with
> complains that `program' has conflicting declarations: once in
> libcpp.h as having
> C++ linkage, once in toplev.h with a C declaration.  It is the
> tradition in modern
> C++ to avoid having many `sources' for the same declaration.

Yes.  I'm working around that for now by editing toplev.h, to avoid
pushing libcpp and libiberty to C++ right away.

#ifdef __cplusplus
extern "C" {
#endif

/* This is used by cpplib and libiberty.  */
extern const char *progname;

#ifdef __cplusplus
}
#endif


I'll try to get my current set of patches committed to the branch
later today.

Ian

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Thu, Jun 19, 2008 at 7:24 AM, Ian Lance Taylor <iant@google.com> wrote:

>> The reason I'm asking is that a fresh build o gcc-in-cxx dies on my machine with
>> complains that `program' has conflicting declarations: once in
>> libcpp.h as having
>> C++ linkage, once in toplev.h with a C declaration.  It is the
>> tradition in modern
>> C++ to avoid having many `sources' for the same declaration.
>
> Yes.  I'm working around that for now by editing toplev.h, to avoid
> pushing libcpp and libiberty to C++ right away.
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> /* This is used by cpplib and libiberty.  */
> extern const char *progname;
>
> #ifdef __cplusplus
> }
> #endif

Yes that makes sense.

>
>
> I'll try to get my current set of patches committed to the branch
> later today.

I'll wait until your patches are in.
Thanks!

-- Gaby

Re: gcc-in-cxx branch created

[Joseph S. Myers]

On Thu, 19 Jun 2008, Ian Lance Taylor wrote:

> Yes.  I'm working around that for now by editing toplev.h, to avoid
> pushing libcpp and libiberty to C++ right away.

I'm not convinced there's much value in building libiberty as C++ for GCC, 
given that it needs to remain buildable as C for now for the other 
projects using it and those projects may be built along with GCC in a 
combined tree (so sharing a single build of libiberty for the host).  
Much the same applies to libdecnumber, shared with GDB (and externally 
maintained).  (I can however see the potential use of a library of C++ 
infrastructure shared between any C++ host tools in GCC and src, but think 
that would best be kept separate from libiberty.  Much of libiberty could 
probably do with being replaced by, or merged into, gnulib anyway.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Thu, 19 Jun 2008, Ian Lance Taylor wrote:
>
>> Yes.  I'm working around that for now by editing toplev.h, to avoid
>> pushing libcpp and libiberty to C++ right away.
>
> I'm not convinced there's much value in building libiberty as C++ for GCC, 
> given that it needs to remain buildable as C for now for the other 
> projects using it and those projects may be built along with GCC in a 
> combined tree (so sharing a single build of libiberty for the host).  

Good point.

Ian

Re: gcc-in-cxx branch created

[Jens-Michael Hoffmann]

Am Mittwoch, 18. Juni 2008 08:01:35 schrieb Ian Lance Taylor:

> I have not yet committed any patches to the branch--at present it is
> just a copy of the trunk.  I will start committing patches soon, and
> anybody else may submit patches as well.  The branch will follow the
> usual gcc maintainership rules, except that any non-algorithmic
> maintainer may additionally approve or commit patches which permit
> compilation with C++.

Should the branch compile right now? I'm asking because I get the following
error when I try to bootstrap:

make[3]: Entering directory `/home/jm/src/gcc/gcc-in-cxx/build/gcc'
g++ -x 
c++ -c  -g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros                                     -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber  ../../gcc/gcc/c-lang.c -o 
c-lang.o
In file included from ../../gcc/gcc/double-int.h:24,
                 from ../../gcc/gcc/tree.h:30,
                 from ../../gcc/gcc/c-lang.c:26:
/usr/include/gmp.h:520: Fehler: »std::FILE« wurde nicht deklariert


Best regards

Jens-Michael

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Jens-Michael Hoffmann <jensmh@gmx.de> writes:

> Am Mittwoch, 18. Juni 2008 08:01:35 schrieb Ian Lance Taylor:
>
>> I have not yet committed any patches to the branch--at present it is
>> just a copy of the trunk.  I will start committing patches soon, and
>> anybody else may submit patches as well.  The branch will follow the
>> usual gcc maintainership rules, except that any non-algorithmic
>> maintainer may additionally approve or commit patches which permit
>> compilation with C++.
>
> Should the branch compile right now?

No.  I've flipped the branch to start compiling the source files in
gcc with C++.  Unfortunately a number of issues will need to be
addressed before all the code will compile in C++.  Most of this work
can and will be contributed back to mainline gcc as well.

I'll send out a note when everything on the branch compiles in C++.

Ian

Re: gcc-in-cxx branch created

[Jens-Michael Hoffmann]

Am Donnerstag, 19. Juni 2008 18:20:43 schrieb Ian Lance Taylor:

> > Should the branch compile right now?
>
> No.  I've flipped the branch to start compiling the source files in
> gcc with C++.  Unfortunately a number of issues will need to be
> addressed before all the code will compile in C++.  Most of this work
> can and will be contributed back to mainline gcc as well.
>
> I'll send out a note when everything on the branch compiles in C++.

Is there a todo list? I would like to contribute to this branch, how can I 
help?

Jens-Michael

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Jens-Michael Hoffmann <jensmh@gmx.de> writes:

>> No.  I've flipped the branch to start compiling the source files in
>> gcc with C++.  Unfortunately a number of issues will need to be
>> addressed before all the code will compile in C++.  Most of this work
>> can and will be contributed back to mainline gcc as well.
>>
>> I'll send out a note when everything on the branch compiles in C++.
>
> Is there a todo list? I would like to contribute to this branch, how can I 
> help?

Well, one approach would be to compile code on the branch.  Where it
fails, fix it so that it compiles.  Then, if appropriate, move the
patch back to mainline, test the patch there, and submit it for
mainline.

The other major TODO is to work out the details of using STL
containers with GC allocated objects.  This means teaching gengtype
how to generate code to traverse STL containers, which would then be
used during GC.  This is not a task for the faint-hearted.

Ian

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Ian Lance Taylor wrote:

> > These are mechanical and can be fixed with simple casts.  Again, IMHO
> > these non-controversial patches should go straight into mainline.
> > Once done we can -Werror this warning and avoid regressions.
>
> Yes, I agree.
> Ian

Okay, the patch to activate -Wc++-compat is installed on mainline.  I'd
like to clean up some of the new warnings, but it sounds like you've got
some of this already done behind the scenes.  E.g.:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01264.html

I'd like to avoid stomping on each other and duplicating work.  Can you
tell me what you've already done and/or plan to do?

Also from a workflow perspective, if I fix the void*->T* warnings from
-Wc++-compat, I'd like to just put them on mainline first and let you
merge it to the branch rather than the reverse.  Mainline is blathering
lots of new warnings right now and I'd like to address those quickly.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

"Kaveh R. GHAZI" <ghazi@caip.rutgers.edu> writes:

> Okay, the patch to activate -Wc++-compat is installed on mainline.  I'd
> like to clean up some of the new warnings, but it sounds like you've got
> some of this already done behind the scenes.  E.g.:
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01264.html
>
> I'd like to avoid stomping on each other and duplicating work.  Can you
> tell me what you've already done and/or plan to do?

I have a bunch of patches, but as far as getting them into mainline
I'm limited by the time it takes to run a bootstrap and test run (I'm
at the summit and am just working on my laptop).  Right now I am
testing the appended patch for mainline; that should clear up a lot of
enum warnings.  I recommend applying this patch to your working
directory, and look at the warnings that remain.

Other than that, everything I've done is minor stuff like the message
to which you refer.  I don't know how to avoid duplicating work at
that level.  If you want to pick a set of files to start with, that
works for me.

> Also from a workflow perspective, if I fix the void*->T* warnings from
> -Wc++-compat, I'd like to just put them on mainline first and let you
> merge it to the branch rather than the reverse.  Mainline is blathering
> lots of new warnings right now and I'd like to address those quickly.

Yes, agreed.

Ian


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Combine all tree codes together --]
[-- Type: text/x-patch, Size: 22325 bytes --]

Index: gencheck.c
===================================================================
--- gencheck.c	(revision 136955)
+++ gencheck.c	(working copy)
@@ -26,12 +26,12 @@ along with GCC; see the file COPYING3.  
 #define DEFTREECODE(SYM, NAME, TYPE, LEN) #SYM,
 
 static const char *const tree_codes[] = {
-#include "tree.def"
-#include "c-common.def"
-#include "gencheck.h"
+#include "all-tree.def"
 (char*) 0
 };
 
+#undef DEFTREECODE
+
 static void usage (void);
 
 static void
Index: java/Make-lang.in
===================================================================
--- java/Make-lang.in	(revision 136955)
+++ java/Make-lang.in	(working copy)
@@ -242,7 +242,7 @@ java.stagefeedback: stageprofile-start
 
 #\f
 # .o:.h dependencies.
-JAVA_TREE_H = $(TREE_H) $(HASHTAB_H) java/java-tree.h java/java-tree.def
+JAVA_TREE_H = $(TREE_H) $(HASHTAB_H) java/java-tree.h
 
 java/jcf-dump.o: $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(JAVA_TREE_H) \
   java/jcf-dump.c java/jcf-reader.c java/jcf.h java/javaop.h java/javaop.def \
Index: java/lang.c
===================================================================
--- java/lang.c	(revision 136955)
+++ java/lang.c	(working copy)
@@ -69,43 +69,6 @@ static enum classify_record java_classif
 # define TARGET_OBJECT_SUFFIX ".o"
 #endif
 
-/* Table indexed by tree code giving a string containing a character
-   classifying the tree code.  Possibilities are
-   t, d, s, c, r, <, 1 and 2.  See java/java-tree.def for details.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
-
-const enum tree_code_class tree_code_type[] = {
-#include "tree.def"
-  tcc_exceptional,
-#include "java-tree.def"
-};
-#undef DEFTREECODE
-
-/* Table indexed by tree code giving number of expression
-   operands beyond the fixed part of the node structure.
-   Not used for types or decls.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
-
-const unsigned char tree_code_length[] = {
-#include "tree.def"
-  0,
-#include "java-tree.def"
-};
-#undef DEFTREECODE
-
-/* Names of tree components.
-   Used for printing out the tree and error messages.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
-
-const char *const tree_code_name[] = {
-#include "tree.def"
-  "@@dummy",
-#include "java-tree.def"
-};
-#undef DEFTREECODE
-
 /* Table of machine-independent attributes.  */
 const struct attribute_spec java_attribute_table[] =
 {
Index: java/java-tree.h
===================================================================
--- java/java-tree.h	(revision 136955)
+++ java/java-tree.h	(working copy)
@@ -30,15 +30,6 @@ The Free Software Foundation is independ
 
 #include "hashtab.h"
 
-/* Java language-specific tree codes.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) SYM,
-enum java_tree_code {
-  __DUMMY = LAST_AND_UNUSED_TREE_CODE,
-#include "java-tree.def"
-  LAST_JAVA_TREE_CODE
-};
-#undef DEFTREECODE
-
 struct JCF;
 
 /* Usage of TREE_LANG_FLAG_?:
Index: tree.c
===================================================================
--- tree.c	(revision 136955)
+++ tree.c	(working copy)
@@ -52,6 +52,38 @@ along with GCC; see the file COPYING3.  
 #include "pointer-set.h"
 #include "fixed-value.h"
 
+/* Tree code classes.  */
+
+#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
+
+const enum tree_code_class tree_code_type[] = {
+#include "all-tree.def"
+};
+
+#undef DEFTREECODE
+
+/* Table indexed by tree code giving number of expression
+   operands beyond the fixed part of the node structure.
+   Not used for types or decls.  */
+
+#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
+
+const unsigned char tree_code_length[] = {
+#include "all-tree.def"
+};
+
+#undef DEFTREECODE
+
+/* Names of tree components.
+   Used for printing out the tree and error messages.  */
+#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
+
+const char *const tree_code_name[] = {
+#include "all-tree.def"
+};
+
+#undef DEFTREECODE
+
 /* Each tree code class has an associated string representation.
    These must correspond to the tree_code_class entries.  */
 
Index: tree.h
===================================================================
--- tree.h	(revision 136955)
+++ tree.h	(working copy)
@@ -35,7 +35,7 @@ along with GCC; see the file COPYING3.  
 #define DEFTREECODE(SYM, STRING, TYPE, NARGS)   SYM,
 
 enum tree_code {
-#include "tree.def"
+#include "all-tree.def"
 
   LAST_AND_UNUSED_TREE_CODE	/* A convenient way to get a value for
 				   NUM_TREE_CODES.  */
Index: objc/objc-act.h
===================================================================
--- objc/objc-act.h	(revision 136955)
+++ objc/objc-act.h	(working copy)
@@ -122,24 +122,6 @@ enum gimplify_status objc_gimplify_expr 
 #define OBJC_TYPE_NAME(TYPE) TYPE_NAME(TYPE)
 #define OBJC_SET_TYPE_NAME(TYPE, NAME) (TYPE_NAME (TYPE) = NAME)
 
-/* Define the Objective-C or Objective-C++ language-specific tree codes.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) SYM,
-enum objc_tree_code {
-#if defined (GCC_CP_TREE_H)
-  LAST_BASE_TREE_CODE = LAST_CPLUS_TREE_CODE,
-#else 
-#if defined (GCC_C_TREE_H)
-  LAST_BASE_TREE_CODE = LAST_C_TREE_CODE,
-#else
-  #error You must include <c-tree.h> or <cp/cp-tree.h> before <objc/objc-act.h>
-#endif
-#endif
-#include "objc-tree.def"
-  LAST_OBJC_TREE_CODE
-};
-#undef DEFTREECODE
-
 /* Hash tables to manage the global pool of method prototypes.  */
 
 typedef struct hashed_entry	*hash;
Index: objc/objc-lang.c
===================================================================
--- objc/objc-lang.c	(revision 136955)
+++ objc/objc-lang.c	(working copy)
@@ -56,48 +56,6 @@ static void objc_init_ts (void);
 /* Each front end provides its own lang hook initializer.  */
 const struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 
-/* Table indexed by tree code giving a string containing a character
-   classifying the tree code.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
-
-const enum tree_code_class tree_code_type[] = {
-#include "tree.def"
-  tcc_exceptional,
-#include "c-common.def"
-  tcc_exceptional,
-#include "objc-tree.def"
-};
-#undef DEFTREECODE
-
-/* Table indexed by tree code giving number of expression
-   operands beyond the fixed part of the node structure.
-   Not used for types or decls.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
-
-const unsigned char tree_code_length[] = {
-#include "tree.def"
-  0,
-#include "c-common.def"
-  0,
-#include "objc-tree.def"
-};
-#undef DEFTREECODE
-
-/* Names of tree components.
-   Used for printing out the tree and error messages.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
-
-const char * const tree_code_name[] = {
-#include "tree.def"
-  "@@dummy",
-#include "c-common.def"
-  "@@dummy",
-#include "objc-tree.def"
-};
-#undef DEFTREECODE
-
 /* Lang hook routines common to C and ObjC appear in c-objc-common.c;
    there should be very few (if any) routines below.  */
 
Index: objcp/objcp-lang.c
===================================================================
--- objcp/objcp-lang.c	(revision 136955)
+++ objcp/objcp-lang.c	(working copy)
@@ -56,53 +56,6 @@ static void objcxx_init_ts (void);
 /* Each front end provides its own lang hook initializer.  */
 const struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 
-/* Tree code classes.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
-
-const enum tree_code_class tree_code_type[] = {
-#include "tree.def"
-  tcc_exceptional,
-#include "c-common.def"
-  tcc_exceptional,
-#include "cp-tree.def"
-  tcc_exceptional,
-#include "objc-tree.def"
-};
-#undef DEFTREECODE
-
-/* Table indexed by tree code giving number of expression
-   operands beyond the fixed part of the node structure.
-   Not used for types or decls.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
-
-const unsigned char tree_code_length[] = {
-#include "tree.def"
-  0,
-#include "c-common.def"
-  0,
-#include "cp-tree.def"
-  0,
-#include "objc-tree.def"
-};
-#undef DEFTREECODE
-
-/* Names of tree components.
-   Used for printing out the tree and error messages.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
-
-const char *const tree_code_name[] = {
-#include "tree.def"
-  "@@dummy",
-#include "c-common.def"
-  "@@dummy",
-#include "cp-tree.def"
-  "@@dummy",
-#include "objc-tree.def"
-};
-#undef DEFTREECODE
-
 /* Lang hook routines common to C++ and ObjC++ appear in cp/cp-objcp-common.c;
    there should be very few (if any) routines below.  */
 
Index: cp/decl.c
===================================================================
--- cp/decl.c	(revision 136955)
+++ cp/decl.c	(working copy)
@@ -9771,7 +9771,7 @@ grok_op_properties (tree decl, bool comp
 	gcc_unreachable ();
       }
     while (0);
-  gcc_assert (operator_code != LAST_CPLUS_TREE_CODE);
+  gcc_assert (operator_code != LAST_AND_UNUSED_TREE_CODE);
   SET_OVERLOADED_OPERATOR_CODE (decl, operator_code);
 
   if (class_type)
Index: cp/Make-lang.in
===================================================================
--- cp/Make-lang.in	(revision 136955)
+++ cp/Make-lang.in	(working copy)
@@ -222,7 +222,7 @@ c++.stagefeedback: stagefeedback-start
 #\f
 # .o: .h dependencies.
 CXX_TREE_H = $(TREE_H) cp/name-lookup.h cp/cp-tree.h $(C_COMMON_H) \
-	cp/cp-tree.def c-common.def $(FUNCTION_H) $(VARRAY_H) \
+	c-common.def $(FUNCTION_H) $(VARRAY_H) \
 	$(SYSTEM_H) coretypes.h $(CONFIG_H) $(TARGET_H) $(GGC_H) \
 	$(srcdir)/../include/hashtab.h $(srcdir)/../include/splay-tree.h
 
Index: cp/mangle.c
===================================================================
--- cp/mangle.c	(revision 136955)
+++ cp/mangle.c	(working copy)
@@ -2108,7 +2108,7 @@ write_expression (tree expr)
 	      /* Unfortunately, there is no easy way to go from the
 		 name of the operator back to the corresponding tree
 		 code.  */
-	      for (i = 0; i < LAST_CPLUS_TREE_CODE; ++i)
+	      for (i = 0; i < LAST_AND_UNUSED_TREE_CODE; ++i)
 		if (operator_name_info[i].identifier == member)
 		  {
 		    /* The ABI says that we prefer binary operator
Index: cp/cp-tree.h
===================================================================
--- cp/cp-tree.h	(revision 136955)
+++ cp/cp-tree.h	(working copy)
@@ -926,15 +926,6 @@ struct language_function GTY(())
   ((NODE) == error_mark_node					\
    || ((NODE) && TREE_TYPE ((NODE)) == error_mark_node))
 \f
-/* C++ language-specific tree codes.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) SYM,
-enum cplus_tree_code {
-  CP_DUMMY_TREE_CODE = LAST_C_TREE_CODE,
-#include "cp-tree.def"
-  LAST_CPLUS_TREE_CODE
-};
-#undef DEFTREECODE
-
 /* TRUE if a tree code represents a statement.  */
 extern bool statement_code_p[MAX_TREE_CODES];
 
@@ -3865,10 +3856,10 @@ typedef struct operator_name_info_t GTY(
 
 /* A mapping from tree codes to operator name information.  */
 extern GTY(()) operator_name_info_t operator_name_info
-  [(int) LAST_CPLUS_TREE_CODE];
+  [(int) LAST_AND_UNUSED_TREE_CODE];
 /* Similar, but for assignment operators.  */
 extern GTY(()) operator_name_info_t assignment_operator_name_info
-  [(int) LAST_CPLUS_TREE_CODE];
+  [(int) LAST_AND_UNUSED_TREE_CODE];
 
 /* A type-qualifier, or bitmask therefore, using the TYPE_QUAL
    constants.  */
Index: cp/cp-lang.c
===================================================================
--- cp/cp-lang.c	(revision 136955)
+++ cp/cp-lang.c	(working copy)
@@ -61,47 +61,6 @@ static enum classify_record cp_classify_
 /* Each front end provides its own lang hook initializer.  */
 const struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 
-/* Tree code classes.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
-
-const enum tree_code_class tree_code_type[] = {
-#include "tree.def"
-  tcc_exceptional,
-#include "c-common.def"
-  tcc_exceptional,
-#include "cp-tree.def"
-};
-#undef DEFTREECODE
-
-/* Table indexed by tree code giving number of expression
-   operands beyond the fixed part of the node structure.
-   Not used for types or decls.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
-
-const unsigned char tree_code_length[] = {
-#include "tree.def"
-  0,
-#include "c-common.def"
-  0,
-#include "cp-tree.def"
-};
-#undef DEFTREECODE
-
-/* Names of tree components.
-   Used for printing out the tree and error messages.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
-
-const char *const tree_code_name[] = {
-#include "tree.def"
-  "@@dummy",
-#include "c-common.def"
-  "@@dummy",
-#include "cp-tree.def"
-};
-#undef DEFTREECODE
-
 /* Lang hook routines common to C++ and ObjC++ appear in cp/cp-objcp-common.c;
    there should be very few routines below.  */
 
Index: cp/lex.c
===================================================================
--- cp/lex.c	(revision 136955)
+++ cp/lex.c	(working copy)
@@ -89,9 +89,10 @@ cxx_finish (void)
 }
 
 /* A mapping from tree codes to operator name information.  */
-operator_name_info_t operator_name_info[(int) LAST_CPLUS_TREE_CODE];
+operator_name_info_t operator_name_info[(int) LAST_AND_UNUSED_TREE_CODE];
 /* Similar, but for assignment operators.  */
-operator_name_info_t assignment_operator_name_info[(int) LAST_CPLUS_TREE_CODE];
+operator_name_info_t
+assignment_operator_name_info[(int) LAST_AND_UNUSED_TREE_CODE];
 
 /* Initialize data structures that keep track of operator names.  */
 
Index: tree-browser.c
===================================================================
--- tree-browser.c	(revision 136955)
+++ tree-browser.c	(working copy)
@@ -73,7 +73,7 @@ struct tb_tree_code {
 #define DEFTREECODE(SYM, STRING, TYPE, NARGS) { SYM, STRING, sizeof (STRING) - 1 },
 static const struct tb_tree_code tb_tree_codes[] =
 {
-#include "tree.def"
+#include "all-tree.def"
 };
 #undef DEFTREECODE
 
Index: ada/Make-lang.in
===================================================================
--- ada/Make-lang.in	(revision 136955)
+++ ada/Make-lang.in	(working copy)
@@ -980,7 +980,7 @@ ada/sdefault.o : ada/ada.ads ada/a-excep
    ada/s-wchcon.ads ada/system.ads ada/table.adb ada/table.ads ada/tree_io.ads \
    ada/types.ads ada/unchdeal.ads ada/unchconv.ads
 
-ADA_TREE_H = ada/ada-tree.h ada/ada-tree.def
+ADA_TREE_H = ada/ada-tree.h
 
 # force debugging information on s-tasdeb.o so that it is always
 # possible to set conditional breakpoints on tasks.
Index: ada/ada-tree.h
===================================================================
--- ada/ada-tree.h	(revision 136955)
+++ ada/ada-tree.h	(working copy)
@@ -23,15 +23,6 @@
  *                                                                          *
  ****************************************************************************/
 
-/* Ada language-specific GC tree codes.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) SYM,
-enum gnat_tree_code {
-  __DUMMY = LAST_AND_UNUSED_TREE_CODE,
-#include "ada-tree.def"
-  LAST_GNAT_TREE_CODE
-};
-#undef DEFTREECODE
-
 /* Ada uses the lang_decl and lang_type fields to hold a tree.  */
 union lang_tree_node
   GTY((desc ("0"),
Index: ada/misc.c
===================================================================
--- ada/misc.c	(revision 136955)
+++ ada/misc.c	(working copy)
@@ -160,45 +160,6 @@ static tree gnat_type_max_size		(const_t
 
 const struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 
-/* Tables describing GCC tree codes used only by GNAT.
-
-   Table indexed by tree code giving a string containing a character
-   classifying the tree code.  Possibilities are
-   t, d, s, c, r, <, 1 and 2.  See cp-tree.def for details.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
-
-const enum tree_code_class tree_code_type[] = {
-#include "tree.def"
-  tcc_exceptional,
-#include "ada-tree.def"
-};
-#undef DEFTREECODE
-
-/* Table indexed by tree code giving number of expression
-   operands beyond the fixed part of the node structure.
-   Not used for types or decls.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
-
-const unsigned char tree_code_length[] = {
-#include "tree.def"
-  0,
-#include "ada-tree.def"
-};
-#undef DEFTREECODE
-
-/* Names of tree components.
-   Used for printing out the tree and error messages.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
-
-const char *const tree_code_name[] = {
-#include "tree.def"
-  "@@dummy",
-#include "ada-tree.def"
-};
-#undef DEFTREECODE
-
 /* How much we want of our DWARF extensions.  Some of our dwarf+ extensions
    are incompatible with regular GDB versions, so we must make sure to only
    produce them on explicit request.  This is eventually reflected into the
Index: fortran/f95-lang.c
===================================================================
--- fortran/f95-lang.c	(revision 136955)
+++ fortran/f95-lang.c	(working copy)
@@ -154,40 +154,6 @@ static alias_set_type gfc_get_alias_set 
 
 const struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 
-/* A list (chain of TREE_LIST nodes) of all LABEL_DECLs in the function
-   that have names.  Here so we can clear out their names' definitions
-   at the end of the function.  */
-
-/* Tree code classes.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
-
-const enum tree_code_class tree_code_type[] = {
-#include "tree.def"
-};
-#undef DEFTREECODE
-
-/* Table indexed by tree code giving number of expression
-   operands beyond the fixed part of the node structure.
-   Not used for types or decls.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
-
-const unsigned char tree_code_length[] = {
-#include "tree.def"
-};
-#undef DEFTREECODE
-
-/* Names of tree components.
-   Used for printing out the tree and error messages.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
-
-const char *const tree_code_name[] = {
-#include "tree.def"
-};
-#undef DEFTREECODE
-
-
 #define NULL_BINDING_LEVEL (struct binding_level *) NULL
 
 /* A chain of binding_level structures awaiting reuse.  */
Index: c-common.h
===================================================================
--- c-common.h	(revision 136955)
+++ c-common.h	(working copy)
@@ -763,16 +763,6 @@ extern void finish_file	(void);
 #define COMPOUND_LITERAL_EXPR_DECL(NODE)			\
   DECL_EXPR_DECL (COMPOUND_LITERAL_EXPR_DECL_STMT (NODE))
 
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) SYM,
-
-enum c_tree_code {
-  C_DUMMY_TREE_CODE = LAST_AND_UNUSED_TREE_CODE,
-#include "c-common.def"
-  LAST_C_TREE_CODE
-};
-
-#undef DEFTREECODE
-
 extern int anon_aggr_type_p (const_tree);
 
 /* For a VAR_DECL that is an anonymous union, these are the various
Index: Makefile.in
===================================================================
--- Makefile.in	(revision 136955)
+++ Makefile.in	(working copy)
@@ -772,7 +772,8 @@ RTL_BASE_H = rtl.h rtl.def $(MACHMODE_H)
 RTL_H = $(RTL_BASE_H) genrtl.h
 PARAMS_H = params.h params.def
 BUILTINS_DEF = builtins.def sync-builtins.def omp-builtins.def
-TREE_H = tree.h tree.def $(MACHMODE_H) tree-check.h $(BUILTINS_DEF) \
+TREE_H = tree.h all-tree.def tree.def c-common.def $(lang_tree_files) \
+          $(MACHMODE_H) tree-check.h $(BUILTINS_DEF) \
           input.h statistics.h vec.h treestruct.def $(HASHTAB_H) \
           double-int.h alias.h
 BASIC_BLOCK_H = basic-block.h bitmap.h sbitmap.h varray.h $(PARTITION_H) \
@@ -1376,6 +1377,18 @@ ifneq ($(xmake_file),)
 include $(xmake_file)
 endif
 
+# all-tree.def includes all the tree.def files.
+all-tree.def: s-alltree; @true
+s-alltree: Makefile
+	rm -f tmp-all-tree.def
+	echo '#include "tree.def"' > tmp-all-tree.def
+	echo '#include "c-common.def"' >> tmp-all-tree.def
+	ltf="$(lang_tree_files)"; for f in $$ltf; do \
+	  echo "#include \"$$f\""; \
+	done | sed 's|$(srcdir)/||' >> tmp-all-tree.def
+	$(SHELL) $(srcdir)/../move-if-change tmp-all-tree.def all-tree.def
+	$(STAMP) s-alltree
+
 #\f
 
 # -----------------------------
@@ -1984,7 +1997,7 @@ langhooks.o : langhooks.c $(CONFIG_H) $(
    langhooks.h $(LANGHOOKS_DEF_H) $(FLAGS_H) $(GGC_H) $(DIAGNOSTIC_H) intl.h \
    $(TREE_GIMPLE_H)
 tree.o : tree.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
-   $(FLAGS_H) $(FUNCTION_H) $(PARAMS_H) \
+   all-tree.def $(FLAGS_H) $(FUNCTION_H) $(PARAMS_H) \
    toplev.h $(GGC_H) $(HASHTAB_H) $(TARGET_H) output.h $(TM_P_H) langhooks.h \
    $(REAL_H) gt-tree.h tree-iterator.h $(BASIC_BLOCK_H) $(TREE_FLOW_H) \
    $(OBSTACK_H) pointer-set.h fixed-value.h
@@ -3239,7 +3252,7 @@ build/genattrtab.o : genattrtab.c $(RTL_
 build/genautomata.o : genautomata.c $(RTL_BASE_H) $(OBSTACK_H)		\
   $(BCONFIG_H) $(SYSTEM_H) coretypes.h $(GTM_H) errors.h vec.h		\
   $(HASHTAB_H) gensupport.h
-build/gencheck.o : gencheck.c gencheck.h tree.def $(BCONFIG_H) $(GTM_H)	\
+build/gencheck.o : gencheck.c tree.def $(BCONFIG_H) $(GTM_H)		\
 	$(SYSTEM_H) coretypes.h $(lang_tree_files)
 build/genchecksum.o : genchecksum.c $(BCONFIG_H) $(SYSTEM_H) $(MD5_H)
 build/gencodes.o : gencodes.c $(RTL_BASE_H) $(BCONFIG_H) $(SYSTEM_H)	\
@@ -3863,7 +3876,7 @@ mostlyclean: lang.mostlyclean
 	-rm -f mddeps.mk
 # Delete other built files.
 	-rm -f xsys-protos.hT
-	-rm -f specs.h gencheck.h options.c options.h
+	-rm -f specs.h options.c options.h
 # Delete the stamp and temporary files.
 	-rm -f s-* tmp-* stamp-* stmp-*
 	-rm -f */stamp-* */tmp-*
Index: c-lang.c
===================================================================
--- c-lang.c	(revision 136955)
+++ c-lang.c	(working copy)
@@ -47,41 +47,6 @@ enum c_language_kind c_language = clk_c;
 /* Each front end provides its own lang hook initializer.  */
 const struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
 
-/* Tree code classes.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
-
-const enum tree_code_class tree_code_type[] = {
-#include "tree.def"
-  tcc_exceptional,
-#include "c-common.def"
-};
-#undef DEFTREECODE
-
-/* Table indexed by tree code giving number of expression
-   operands beyond the fixed part of the node structure.
-   Not used for types or decls.  */
-
-#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
-
-const unsigned char tree_code_length[] = {
-#include "tree.def"
-  0,
-#include "c-common.def"
-};
-#undef DEFTREECODE
-
-/* Names of tree components.
-   Used for printing out the tree and error messages.  */
-#define DEFTREECODE(SYM, NAME, TYPE, LEN) NAME,
-
-const char *const tree_code_name[] = {
-#include "tree.def"
-  "@@dummy",
-#include "c-common.def"
-};
-#undef DEFTREECODE
-
 /* Final processing of file-scope data.  The Objective-C version of
    this function still does something.  */
 void

Re: gcc-in-cxx branch created

[Daniel Berlin]

On Thu, Jun 19, 2008 at 1:26 PM, Ian Lance Taylor <iant@google.com> wrote:
> Jens-Michael Hoffmann <jensmh@gmx.de> writes:
>
>>> No.  I've flipped the branch to start compiling the source files in
>>> gcc with C++.  Unfortunately a number of issues will need to be
>>> addressed before all the code will compile in C++.  Most of this work
>>> can and will be contributed back to mainline gcc as well.
>>>
>>> I'll send out a note when everything on the branch compiles in C++.
>>
>> Is there a todo list? I would like to contribute to this branch, how can I
>> help?
>
> Well, one approach would be to compile code on the branch.  Where it
> fails, fix it so that it compiles.  Then, if appropriate, move the
> patch back to mainline, test the patch there, and submit it for
> mainline.
>
> The other major TODO is to work out the details of using STL
> containers with GC allocated objects.  This means teaching gengtype
> how to generate code to traverse STL containers, which would then be
> used during GC.  This is not a task for the faint-hearted.
>

One way to avoid having gengtype generate the walks is to have a
container base class that implements walking using iterators.   Then
we can have gcc::vector instead of std::vector, etc.

Gengtype would then just have to use this interface when walking
container roots, instead of having to generate it's own walking
functions for containers.

Then again, it's not clear this is worth it, since at some point you
will probably want to have a base class for gc'd objects and have the
walking function be a member, instead of what gengtype does now, so
gengtype will have to learn some stuff anway.

Re: gcc-in-cxx branch created

[Paweł Sikora]

On Thursday 19 of June 2008 19:26:27 Ian Lance Taylor wrote:
> Jens-Michael Hoffmann <jensmh@gmx.de> writes:
> >> No.  I've flipped the branch to start compiling the source files in
> >> gcc with C++.  Unfortunately a number of issues will need to be
> >> addressed before all the code will compile in C++.  Most of this work
> >> can and will be contributed back to mainline gcc as well.
> >>
> >> I'll send out a note when everything on the branch compiles in C++.
> >
> > Is there a todo list? I would like to contribute to this branch, how can
> > I help?
>
> Well, one approach would be to compile code on the branch.  Where it
> fails, fix it so that it compiles.  Then, if appropriate, move the
> patch back to mainline, test the patch there, and submit it for
> mainline.
>
> The other major TODO is to work out the details of using STL
> containers with GC allocated objects.

there's also a http://www.aei.mpg.de/~peekas/tree/ that may be useful
for modeling abstract trees used in compiler.

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Paweł Sikora <pluto@agmk.net> writes:

> there's also a http://www.aei.mpg.de/~peekas/tree/ that may be useful
> for modeling abstract trees used in compiler.

Thanks.  I want to be clear that the initial goal of the gcc-in-cxx
branch will be to produce code which is quite close to mainline, but
compiles gcc with C++.  Changing the structure of tree to be a class
would be appropriate for a different branch, probably one based on
gcc-in-cxx.

Ian

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Ian Lance Taylor wrote:

> "Kaveh R. GHAZI" <ghazi@caip.rutgers.edu> writes:
>
> > I'd like to avoid stomping on each other and duplicating work.  Can you
> > tell me what you've already done and/or plan to do?
>
> I have a bunch of patches, but as far as getting them into mainline
> I'm limited by the time it takes to run a bootstrap and test run (I'm
> at the summit and am just working on my laptop).  Right now I am
> testing the appended patch for mainline; that should clear up a lot of
> enum warnings.  I recommend applying this patch to your working
> directory, and look at the warnings that remain.
>
> Other than that, everything I've done is minor stuff like the message
> to which you refer.  I don't know how to avoid duplicating work at
> that level.  If you want to pick a set of files to start with, that
> works for me.

Okay, looks like you have the enum problem under control.  I'm attacking
the void*->T* problem on mainline.  So far I've got most of the java
directory, the objc directory and a few top level files (gcc.c,
collect2.c, tlink.c) done and it's undergoing regtesting.  I'll install as
"obvious" on mainline since it's just casting and/or using the libiberty
C++ macros created explicitly for this purpose.

I'll do fortran next, then some top level files.  I'll post in this thread
which ones so we don't overlap.  Please do the same.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: gcc-in-cxx branch created

[Aaron Gray]

Hi,

Just in case you are interested in it I have a 4.2.1 compiling and built 
using C++.

I have not really worked on it for quite a while now.

        http://www.gccpp.org

Download at :-

        http://www.gccpp.org/download/

Aaron

Re: gcc-in-cxx branch created

[Kaveh R. GHAZI]

On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:

> I'll do fortran next, then some top level files.  I'll post in this thread
> which ones so we don't overlap.  Please do the same.

Okay, I'm starting on the top level files.  I'll go backwards through the
alphabet.  Doing [t-z]* right now, that's probably all I'll get to today.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: gcc-in-cxx branch created

[Ivan Levashew]

Ian Lance Taylor ГЇГЁГёГҐГІ:
> As I promised at the summit today, I have created the branch
> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
> better to avoid possible meta-characters).  The goal of this branch is
> to develop a version of gcc which is compiled with C++.  Here are my
> presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf .
> 
Well, C's macros are ugly, but C++ isn't a way to go either. The fact 
that C++ is partially implemented in GCC and belongs to the GCC main 
distribution is the only excuse for choosing C++.


-- 
If you want to get to the top, you have to start at the bottom

Re: gcc-in-cxx branch created

[Ivan Levashew]

Ian Lance Taylor пишет:
> 
> The other major TODO is to work out the details of using STL
> containers with GC allocated objects.  This means teaching gengtype
> how to generate code to traverse STL containers, which would then be
> used during GC.  This is not a task for the faint-hearted.
> 
That's one of the many reasons against C++. Even damn Cyclone will beat 
C++ here.

-- 
If you want to get to the top, you have to start at the bottom

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Ivan Levashew <I.Levashew@bluebottle.com> writes:

> Ian Lance Taylor пишет:
>>
>> The other major TODO is to work out the details of using STL
>> containers with GC allocated objects.  This means teaching gengtype
>> how to generate code to traverse STL containers, which would then be
>> used during GC.  This is not a task for the faint-hearted.
>>
> That's one of the many reasons against C++. Even damn Cyclone will
> beat C++ here.

Your comment makes little sense in context.  Nobody could claim that
the existing gengtype code is simple.  Not many people understand how
it works at all.  In order to support STL containers holding GC
objects, it will need to be modified.  The fact that modifying it is
nontrivial is not an argument either for or against C++.

I don't know what you mean by your reference to the Cyclone variant of
C, unless you are trying to say something about gcc's use of garbage
collection.

Ian

Re: gcc-in-cxx branch created

[Tom Tromey]

>>>>> "Ian" == Ian Lance Taylor <iant@google.com> writes:

Ian> The other major TODO is to work out the details of using STL
Ian> containers with GC allocated objects.  This means teaching gengtype
Ian> how to generate code to traverse STL containers, which would then be
Ian> used during GC.  This is not a task for the faint-hearted.

A related (and IMO probably more difficult) problem is that of
serializing such containers for PCH.

Tom

Re: gcc-in-cxx branch created

[Richard Guenther]

On Tue, Jun 24, 2008 at 3:54 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Ian" == Ian Lance Taylor <iant@google.com> writes:
>
> Ian> The other major TODO is to work out the details of using STL
> Ian> containers with GC allocated objects.  This means teaching gengtype
> Ian> how to generate code to traverse STL containers, which would then be
> Ian> used during GC.  This is not a task for the faint-hearted.
>
> A related (and IMO probably more difficult) problem is that of
> serializing such containers for PCH.

One more reason to get rid of our current PCH implementation ...

:)

Richard.

Re: gcc-in-cxx branch created

[Tom Tromey]

>>>>> "Kaveh" == Kaveh R GHAZI <ghazi@caip.rutgers.edu> writes:

Kaveh> We could also extend -Wc++-compat to warn about more things, using C++
Kaveh> reserved keywords like "class" in C comes to mind.

This isn't super hard, and IMO is worth doing (right now -Wc++-compat
seems almost silly in its limitations), but in lieu of implementing
this I've just been using #pragma GCC poison.

Tom

Re: gcc-in-cxx branch created

[Ivan Levashew]

Ian Lance Taylor пишет:
> Ivan Levashew <I.Levashew@bluebottle.com> writes:
> 
>> Ian Lance Taylor пишет:
>>> The other major TODO is to work out the details of using STL
>>> containers with GC allocated objects.  This means teaching gengtype
>>> how to generate code to traverse STL containers, which would then be
>>> used during GC.  This is not a task for the faint-hearted.
>>>
>> That's one of the many reasons against C++. Even damn Cyclone will
>> beat C++ here.
> 
> Your comment makes little sense in context.  Nobody could claim that
> the existing gengtype code is simple.  Not many people understand how
> it works at all.  In order to support STL containers holding GC
> objects, it will need to be modified.

I'm sure there is a library of GC-managed components in C++.

> The fact that modifying it is
> nontrivial is not an argument either for or against C++.

Bruno has a better critique on C++.

> 
> I don't know what you mean by your reference to the Cyclone variant of
> C, unless you are trying to say something about gcc's use of garbage
> collection.
> 

Cyclone has many options for memory management. I don't know for sure if 
there is a need for GC in GCC at all.
Cyclone has a roots not only in C, but also ML. Some techniques like 
pattern matching, aggregates, variadic arrays, tuples looks to be more 
appropriate here than their C++'s metaprogrammed template analogues.

I'm just trying to be constructive.

Compilation is IMHO a task for functional PLs, and ML heritage is a plus.
Cyclone's current implementation compiles into C, so there will be no 
bootstrapping problem as soon as there are C output in the tarballs.
Complexity of porting existing code base to C++ is comparable to one of 
porting it to Cyclone (in contrast to moving it to a functional PL).

-- 
If you want to get to the top, you have to start at the bottom

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Ivan Levashew <I.Levashew@bluebottle.com> writes:

>> Your comment makes little sense in context.  Nobody could claim that
>> the existing gengtype code is simple.  Not many people understand how
>> it works at all.  In order to support STL containers holding GC
>> objects, it will need to be modified.
>
> I'm sure there is a library of GC-managed components in C++.

I'm sure there is too.  In gcc we use the same data structures to
support both GC and PCH.  Switching to a set of C++ objects is likely
to be a complex and ultimately unrewarding task.


>> I don't know what you mean by your reference to the Cyclone variant of
>> C, unless you are trying to say something about gcc's use of garbage
>> collection.
>>
>
> Cyclone has many options for memory management. I don't know for sure
> if there is a need for GC in GCC at all.

I would prefer it if gcc didn't use GC, but it does, and undoing that
decision will be a long hard task which may never get done.

> Cyclone has a roots not only in C, but also ML. Some techniques like
> pattern matching, aggregates, variadic arrays, tuples looks to be more
> appropriate here than their C++'s metaprogrammed template analogues.

I guess I don't know Cyclone.  If you are suggesting that we use
Cyclone instead of C++, I think that is a non-starter.  We need to use
a well-known widely-supported language, and it must be a language
which gcc itself supports.

Ian

Re: gcc-in-cxx branch created

[Hendrik Boom]

On Wed, 25 Jun 2008 20:11:56 -0700, Ian Lance Taylor wrote:

> Ivan Levashew <I.Levashew@bluebottle.com> writes:
> 
>>> Your comment makes little sense in context.  Nobody could claim that
>>> the existing gengtype code is simple.  Not many people understand how
>>> it works at all.  In order to support STL containers holding GC
>>> objects, it will need to be modified.
>>
>> I'm sure there is a library of GC-managed components in C++.
> 
> I'm sure there is too.  In gcc we use the same data structures to
> support both GC and PCH.  Switching to a set of C++ objects is likely to
> be a complex and ultimately unrewarding task.
> 
> 
>>> I don't know what you mean by your reference to the Cyclone variant of
>>> C, unless you are trying to say something about gcc's use of garbage
>>> collection.
>>>
>>>
>> Cyclone has many options for memory management. I don't know for sure
>> if there is a need for GC in GCC at all.
> 
> I would prefer it if gcc didn't use GC, but it does, and undoing that
> decision will be a long hard task which may never get done.
> 
>> Cyclone has a roots not only in C, but also ML. Some techniques like
>> pattern matching, aggregates, variadic arrays, tuples looks to be more
>> appropriate here than their C++'s metaprogrammed template analogues.
> 
> I guess I don't know Cyclone.  If you are suggesting that we use Cyclone
> instead of C++, I think that is a non-starter.  We need to use a
> well-known widely-supported language, and it must be a language which
> gcc itself supports.
> 
> Ian

There are a number of languages that would probably be better-suited to 
programming gcc than C or C++, on technical grounds alone.  Modula-3 
comes to mind.  Cyclone certainly looks like a possibility, and has the 
advantage that it would probebly be less of a shock to the existing code 
base.  But if it is a requirement for using a language that everyone 
already knows it, we will forever be doomed to C and its insecure 
brethren.

-- hendrik

Re: gcc-in-cxx branch created

[Daniel Berlin]

On Wed, Jul 2, 2008 at 2:30 PM, Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> On Wed, 25 Jun 2008 20:11:56 -0700, Ian Lance Taylor wrote:
>
>> Ivan Levashew <I.Levashew@bluebottle.com> writes:
>>
>>>> Your comment makes little sense in context.  Nobody could claim that
>>>> the existing gengtype code is simple.  Not many people understand how
>>>> it works at all.  In order to support STL containers holding GC
>>>> objects, it will need to be modified.
>>>
>>> I'm sure there is a library of GC-managed components in C++.
>>
>> I'm sure there is too.  In gcc we use the same data structures to
>> support both GC and PCH.  Switching to a set of C++ objects is likely to
>> be a complex and ultimately unrewarding task.
>>
>>
>>>> I don't know what you mean by your reference to the Cyclone variant of
>>>> C, unless you are trying to say something about gcc's use of garbage
>>>> collection.
>>>>
>>>>
>>> Cyclone has many options for memory management. I don't know for sure
>>> if there is a need for GC in GCC at all.
>>
>> I would prefer it if gcc didn't use GC, but it does, and undoing that
>> decision will be a long hard task which may never get done.
>>
>>> Cyclone has a roots not only in C, but also ML. Some techniques like
>>> pattern matching, aggregates, variadic arrays, tuples looks to be more
>>> appropriate here than their C++'s metaprogrammed template analogues.
>>
>> I guess I don't know Cyclone.  If you are suggesting that we use Cyclone
>> instead of C++, I think that is a non-starter.  We need to use a
>> well-known widely-supported language, and it must be a language which
>> gcc itself supports.
>>
>> Ian
>
> There are a number of languages that would probably be better-suited to
> programming gcc than C or C++, on technical grounds alone.


That's great.
We have more than just technical concerns.

>   But if it is a requirement for using a language that everyone
> already knows it, we will forever be doomed to C and its insecure
> brethren.
>
This has never been listed as a requirement.
It is certainly a consideration.
The main requirement for communities like GCC for something like
changing languages is consensus or at least a large set of active
developers willing to do something and the rest of them willing to not
commit suicide if it happens.
There are secondary requirements like "not stalling for years while
moving languages", "not losing serious performance", etc.

You are free to propose whatever language you like. It is unlikely you
will get support from any of the active contributors simply saying we
should use X because Y.
The best way to show us the advantages of using some other languages
is to convert some part of GCC to use it and show how much better it
is.

This is a big job, of course.  Then again, tree-ssa was started by
diego as a side project, and gained supporters and helpers as others
decided to spend their time on it.
You may find the same thing, in which case you may find it is not hard
to convince people to move to some other language.
You may find nobody agrees with you, even after seeing parts of gcc in
this new language.
I can guarantee you you will find nobody agrees with you if you sit on
the sidelines and do nothing but complain.

--Dan

Re: gcc-in-cxx branch created

[Hendrik Boom]

Thank you for your thoughtful and patient reply.  I should probably 
apologize for the strident tone of my first letter to this mailing list.  
It reflects a decades-long frustration with the trends in the computer 
industry, rather than a specific critique of ggc development itself.  Gcc 
is a wonderful compiler, and has done a lot for the liberation of 
programming from proprietary shackles.  I am in awe of what its 
developers have accomplished.


On Thu, 03 Jul 2008 02:50:11 -0400, Daniel Berlin wrote:

> On Wed, Jul 2, 2008 at 2:30 PM, Hendrik Boom <hendrik@topoi.pooq.com>
> wrote:
>>
>> There are a number of languages that would probably be better-suited to
>> programming gcc than C or C++, on technical grounds alone.
> 
> 
> That's great.
> We have more than just technical concerns.

I agree.

> 
>>   But if it is a requirement for using a language that everyone
>> already knows it, we will forever be doomed to C and its insecure
>> brethren.
>>
> This has never been listed as a requirement. It is certainly a
> consideration.
> The main requirement for communities like GCC for something like
> changing languages is consensus or at least a large set of active
> developers willing to do something and the rest of them willing to not
> commit suicide if it happens.
> There are secondary requirements like "not stalling for years while
> moving languages", "not losing serious performance", etc.
> 
> You are free to propose whatever language you like. It is unlikely you
> will get support from any of the active contributors simply saying we
> should use X because Y.
> The best way to show us the advantages of using some other languages is
> to convert some part of GCC to use it and show how much better it is.
> 
> This is a big job, of course.  Then again, tree-ssa was started by diego
> as a side project, and gained supporters and helpers as others decided
> to spend their time on it.
> You may find the same thing, in which case you may find it is not hard
> to convince people to move to some other language. You may find nobody
> agrees with you, even after seeing parts of gcc in this new language.
> I can guarantee you you will find nobody agrees with you if you sit on
> the sidelines and do nothing but complain.
> 
> --Dan

I first started using C and Algol 68 in 1975 -- C on a PDP-11, and Algol 
68 on a CDC Cyber.  Without doubt, Algol 68 was a better language for 
most programming, but its operating environment (the NOS operating 
system) was so hostile that I preferred the PDP-11 (with Unix).  It has 
been the Unix operating system that has carried C to the ubiquitous 
presence it has today.

C is a 30-year-old language.  Most people adopt C nowadays because 
everyone else is using it, even though there are much better 20-year-old 
languages available.  I've spent years of my life tracking down dangling 
pointers in other people's C code while hired to do development on 
existing projects, all the while remembering that the first program I 
wrote in Algol 68 was over a thousand lines long, contained complicated 
data structures, and ran correctly the first time it passed through the 
compiler without compile-time diagnostics.

Don't get me wrong.  I can write C.  I can write C++.  I've even written 
a substantial part of a C++ implementation in C++.

That said, I understand the inertia of an existing code base.  Gcc is as 
much the victim of the curse of compatibility as a multitude of other 
projects.  C++ is a big improvement over C, if you can restrict yourself 
to a comprehensible subset (as you are apparently attempting to do).  And 
it has, qua inertia, the enormous advantage that it's possible to 
incrementally move a large project from C to C++.

But I am still frustrated by the enormous pain the industry inflict on 
itself by persisting is using such flawed tools for new projects.

-- hendrik

Re: gcc-in-cxx branch created

[Ross Smith]

Ian Lance Taylor wrote:
> 
> I expect that we will find it appropriate to use STL containers, as in
>   for (Type::iterator p = container.begin(); p != container.end(); ++p)

For loops like this I'd recommend using some kind of FOREACH macro (the 
functional equivalent of BOOST_FOREACH; this is easy to write when you 
can use GCC's typeof feature). I've found that using a FOREACH macro 
improves code readability significantly. Not only is the normal case 
shorter and clearer, but it also means that when you do spell out a for 
loop explicitly, it acts as a signal to the reader that "we're doing 
something more complicated than straightforward iteration here, so read 
carefully".

-- Ross Smith

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Bruno Haible <bruno@clisp.org> writes:

> What is the level of C++ that "new developers" need to master, in order to
> understand the code in general and to fix bugs in average areas?

I don't know.  I think we will have to find out.

I expect that we will find it appropriate to use STL containers, as in
  for (Type::iterator p = container.begin(); p != container.end(); ++p)

I expect we will find it appropriate to use simple class inheritance,
as in
  class Target
  {
    virtual bool handle_option(size_t, const char*, int)
    { return true; }
  };

  class Target_i386 : public Target
  {
    bool handle_option(size_t code, const char* arg, int value)
    {
      ...
    };
  };

When it comes to fixing bugs, I doubt that any special C++ knowledge
will be required at all.  When it comes to writing the code in gcc's
compilation passes, it will pretty much all be C.  Anybody patient
enough to understand the uses of the tree and RTL data structures can
certainly understand C++.

Ian

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Tue, Jun 24, 2008 at 6:20 AM, Bruno Haible <bruno@clisp.org> wrote:
>
> What is the level of C++ that "new developers" need to master, in order to
> understand the code in general and to fix bugs in average areas?
>
> Bruno

What is covered in `Accelerated C++' by A. Koenig should be enough, I would
think; but that is only me.

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Tue, Jun 24, 2008 at 5:47 AM, Bruno Haible <bruno@clisp.org> wrote:
> Gabriel Dos Reis wrote:
>> There is a subset of C++ templates stable enough over the years, that can be
>> used without fear, uncertainty and doubt.
>
> Absolutely. Can you specify this "usable" subset of C++ templates formally?

formally, probably not, but I rely on the common sense of my fellow
maintainers.  To give concreteness to what I mean, I suspect that
most *uses* of the template uses in the STL -- before we get to rvalue
references
and the like are OK.  They don't require cleverness.

> That would be valuable advice for maintainers. So that maintainers can decide
> whether they should write code like gmpxx [1] inside GCC.

the code gmpxx was inpired by my implementation of valarray that comes with
GCC.  I don't think such `execessive cleverness' is needed in the
compiler itself.
In fact, most codes in the compiler should be `dull'.

>
> Bruno
>
> [1] http://www.google.com/codesearch?hl=en&q=show:G8p0bPmV-oQ:iB2K8u4XbxM:9D2oeU5g1Qo&sa=N&cd=1&ct=rc&cs_p=http://gcc-hk.internet.bs/infrastructure/gmp-4.2.1.tar.bz2&cs_f=gmp-4.2.1/gmpxx.h
>
>

Re: gcc-in-cxx branch created

[Bruno Haible]

Ian Lance Taylor wrote:
> Whether we use C or C++, we need to try to ensure that interfaces are
> easy to understand, that the code is reasonably modular, that the
> internal documentation corresponds to the code, that it is possible
> for new developers to write new passes and to fix bugs.

Fully agreed.

> it is possible for most compiler developers to use the vec.h routines
> without understanding how they actually work.

Understood.

What is the level of C++ that "new developers" need to master, in order to
understand the code in general and to fix bugs in average areas?

Bruno

Re: gcc-in-cxx branch created

[Bruno Haible]

Gabriel Dos Reis wrote:
> There is a subset of C++ templates stable enough over the years, that can be
> used without fear, uncertainty and doubt.

Absolutely. Can you specify this "usable" subset of C++ templates formally?
That would be valuable advice for maintainers. So that maintainers can decide
whether they should write code like gmpxx [1] inside GCC.

Bruno

[1] http://www.google.com/codesearch?hl=en&q=show:G8p0bPmV-oQ:iB2K8u4XbxM:9D2oeU5g1Qo&sa=N&cd=1&ct=rc&cs_p=http://gcc-hk.internet.bs/infrastructure/gmp-4.2.1.tar.bz2&cs_f=gmp-4.2.1/gmpxx.h

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Mon, Jun 23, 2008 at 6:14 AM, Bruno Haible <bruno@clisp.org> wrote:
> Arnaud Charlet wrote:
>> One possibility is to do what we do for Ada: have a style/coding checker
>> built into the compiler (C++ front-end) as a special switch, and enable this
>> switch during bootstrap, so that any such coding style violation is transformed
>> into an error
>
> Yes, this can be the technical implementation of limiting the set of C++
> features.
>
> Additionally, it needs to be avoided that the limits get pushed out year
> after year, allowing, for example, inline templates in one year, template
> member functions the next year, and complete template metaprogramming the
> year after that. To this end, it must be made very hard to extend this
> subset of C++. Possibly it should require agreement from the Steering Comittee
> to do so.
>
> Bruno

while `creative' uses of templates are certainly a problem -- we don't
really want
people to start writing clever (which most of the time means brittle)
codes, we should
also refrain from putting FUD on templates.  There is a subset of C++ templates
stable enough over the years, that can be used without fear,
uncertainty and doubt.

I don't see banning inline template as increasing the readability of
GCC codebase.

-- Gaby


>
>

Re: gcc-in-cxx branch created

[Gabriel Dos Reis]

On Sun, Jun 22, 2008 at 6:24 PM, Bruno Haible <bruno@clisp.org> wrote:
> Dear Ian,
>
> A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
>
>  "C++ is too complicated!"
>
> with
>
>  "Maintainers will ensure that gcc continues to be maintainable."
>
> C++ has, for example, 12 different ways to represent or invoke a function.
> It has no buikt-in typesafe "enum"s. Sooner or later developers will think

C++ enums are certainly improvements over C enums.  Below you
mentioned dynamic_cast working with enum sets, I don't what
you mean by that -- since any attempt to dynamic_cast an
enum is rejected at compile time.

-- Gaby

Re: gcc-in-cxx branch created

[Bruno Haible]

Arnaud Charlet wrote:
> One possibility is to do what we do for Ada: have a style/coding checker
> built into the compiler (C++ front-end) as a special switch, and enable this
> switch during bootstrap, so that any such coding style violation is transformed
> into an error

Yes, this can be the technical implementation of limiting the set of C++
features.

Additionally, it needs to be avoided that the limits get pushed out year
after year, allowing, for example, inline templates in one year, template
member functions the next year, and complete template metaprogramming the
year after that. To this end, it must be made very hard to extend this
subset of C++. Possibly it should require agreement from the Steering Comittee
to do so.

Bruno

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Bruno Haible <bruno@clisp.org> writes:

> A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
>
>   "C++ is too complicated!"
>
> with
>
>   "Maintainers will ensure that gcc continues to be maintainable."
>
> C++ has, for example, 12 different ways to represent or invoke a function.
> It has no buikt-in typesafe "enum"s. Sooner or later developers will think
> more about
>   "should this better be a member function or a static inline function?"
>   or "how do I make dynamic_cast work with my enum sets?"
> than about the algorithm they want to implement.
>
> How can maintainers ensure this does not happen?

The point is not to ensure that any particular language feature is not
used.  The language features are not arbitrary; they serve particular
programming techniques.  When those techniques are appropriate, the
language features will be appropriate.

It is possible to write obscure code code in C just as in C++.
Obviously the canonical gcc example of this is vec.h.  Although that
code is obscure, it presents a relatively simple interface.  Thus it
is possible for most compiler developers to use the vec.h routines
without understanding how they actually work.  (As it happens, vec.h
would be much much simpler in C++, but that is not the point I am
making here.)

What matters for gcc going forward is that it continue to be
comprehensible and maintainable.  That is a struggle that gcc has
faced for its entire existence as a free software project.  It is
certainly true that using C++ unwisely can make that struggle more
difficult.  But this issue is not qualitatively different from the
issues we face today.

Whether we use C or C++, we need to try to ensure that interfaces are
easy to understand, that the code is reasonably modular, that the
internal documentation corresponds to the code, that it is possible
for new developers to write new passes and to fix bugs.  Those are the
important issues for us to consider.  The C++ features which are not
present in C--features which are well documented in many books and
many web sites--are not an important issue.

I certainly grant that some programmers new to C++ have been known to
try to use all the advanced C++ features at once, whether or not they
are appropriate.  However, that is not a problem we are going to face
with our existing maintainers, who are all experienced programmers.

Ian

Re: gcc-in-cxx branch created

[Arnaud Charlet]

> I've thought such a thing would be useful for C style as well.

Right. It just becomes more of an issue if people start using C++
which is a much more complex and large language, but it would also benefit
gcc developers today to have C coding standard checked automatically.

> One slight complication is that while a limited subset of C++ should be 
> fine for most of the compiler, there may be a use for many more features 
> (provided those features are still supported by the baseline bootstrap 
> compiler version, e.g. 3.4) in selected areas that provide infrastructure 
> for use in the rest of the compiler (just as now we have complicated 
> macros in vec.h, and maintainers need not care most of the time about the 
> implementations of them, just about how to use them).  So you may have 
> features that should not be freely spread throughout the compiler but 
> should be allowed for particular pieces of code only.

You can use special pragmas or attributes to tell the coding checker which
subset is allowed for a given file.

Arno

Re: gcc-in-cxx branch created

[Joseph S. Myers]

On Mon, 23 Jun 2008, Arnaud Charlet wrote:

> >> How can maintainers ensure this does not happen?
> > 
> > What is your suggestion, stay with C?  It doesn't have type safe enums 
> > either.
> 
> One possibility is to do what we do for Ada: have a style/coding checker
> built into the compiler (C++ front-end) as a special switch, and enable this
> switch during bootstrap, so that any such coding style violation is transformed
> into an error (actually a warning, transformed then into an error with -Werror).

I've thought such a thing would be useful for C style as well.

One slight complication is that while a limited subset of C++ should be 
fine for most of the compiler, there may be a use for many more features 
(provided those features are still supported by the baseline bootstrap 
compiler version, e.g. 3.4) in selected areas that provide infrastructure 
for use in the rest of the compiler (just as now we have complicated 
macros in vec.h, and maintainers need not care most of the time about the 
implementations of them, just about how to use them).  So you may have 
features that should not be freely spread throughout the compiler but 
should be allowed for particular pieces of code only.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-in-cxx branch created

[Arnaud Charlet]

>> How can maintainers ensure this does not happen?
> 
> What is your suggestion, stay with C?  It doesn't have type safe enums 
> either.

One possibility is to do what we do for Ada: have a style/coding checker
built into the compiler (C++ front-end) as a special switch, and enable this
switch during bootstrap, so that any such coding style violation is transformed
into an error (actually a warning, transformed then into an error with -Werror).

Arno

Re: gcc-in-cxx branch created

[Chris Lattner]

On Jun 22, 2008, at 4:24 PM, Bruno Haible wrote:

> Dear Ian,
>
> A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
>
>  "C++ is too complicated!"
>
> with
>
>  "Maintainers will ensure that gcc continues to be maintainable."
>
> C++ has, for example, 12 different ways to represent or invoke a  
> function.
> It has no buikt-in typesafe "enum"s. Sooner or later developers will  
> think
> more about
>  "should this better be a member function or a static inline  
> function?"
>  or "how do I make dynamic_cast work with my enum sets?"
> than about the algorithm they want to implement.
>
> How can maintainers ensure this does not happen?

What is your suggestion, stay with C?  It doesn't have type safe enums  
either.

-Chris

Re: gcc-in-cxx branch created

[Bruno Haible]

Dear Ian,

A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer

  "C++ is too complicated!"

with

  "Maintainers will ensure that gcc continues to be maintainable."

C++ has, for example, 12 different ways to represent or invoke a function.
It has no buikt-in typesafe "enum"s. Sooner or later developers will think
more about
  "should this better be a member function or a static inline function?"
  or "how do I make dynamic_cast work with my enum sets?"
than about the algorithm they want to implement.

How can maintainers ensure this does not happen?

You cannot pick a set of C++ features and say "we will only use these
elementary C++ features, not the complex ones". It won't work because

  1) The compiler forces the developers to use more and more advanced features.
     As soon as you want to use classes, you must learn about inline, const,
     constructors and destructors. People will request that you use namespaces.
     Multiple inheritance is not on your wishlist in the beginning, but you
     will likely use it sooner or later. You can be lucky if you avoid virtual
     inheritance...

  2) Year over year, advanced developers will start relying on even more fancy
     features: templates, exceptions, 'explicit' constructors, Koenig lookup,
     etc. Less advanced developers would like to say "no", but their voice
     doesn't count as much as the voice of advanced developers. So year after
     year, the full set of C++ features gets used.

Bruno