This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] type safe trees
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: aph at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 25 Jun 04 09:06:47 EDT
- Subject: Re: [RFC] type safe trees
I never really expressed my opinion on the issue of using C++ for GCC, so let
me do so now.
I'm against it for two reasons. The first is that I am indeed worried about
"creeping featurism" where we gradually over time use more and more C++
features and eventually don't have much of a subset any more.
But my major concern is bootstrapping, but not in the way that's being
disussed. I'm not too concerned about the case of somebody buying a machine
and not being able to compile GCC. As has been pointed out, buying a
commercial machine means you'll have a C++ compiler.
My concern is the *new machine*. The major strength of GCC has been its
ability to relatively rapidly be ported to a new architecture and brought up
on that machine. Often GCC is the first compiler for that machine and is the
route to getting other things working. You want to make that process go as
smoothly as possible.
At that point, you barely have anything working. You're doing everything on
a cross system. You don't have the assembler and linker debugged yet. The
debugger is limping along and has serious problems. You're relying a lot on
simulators whose fidelity to the hardware hasn't yet completely matured.
You probably still have hardware bugs.
*Every* little bit of complexity in what GCC needs in order to run is going
to be a major burden in that environment. Right now it just needs itself and
a handful of standard library routines.
I've done a number GCC ports to new machines but only once when it was the
first compiler on that machine (and even then there was a cross-compiler
available from a vendor). Most people on this list have done neither of
these, but I'm sure several of you have had more exprience with the "first
compiler" situation than I have.
I see no major problem with using C++ features that are open-coded. But each
time you talk about using a feature that add "hidden" subprograms to the code
which you can't step through in a debugger since there's no source equivalent
(note that GNAT does allow this with -gnatDG) or use more library routines,
you make that initial port process that much harder.
Even though the number of people doing this is very small and the number of
times it's done is small, this process is the most important activity to the
future of GCC and I would be careful in adding to the already high burden of
those people unless we have a *very clear gain* from doing so and I've very
unconvinced we do by the arguments I've seen so far.