This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Converting GCC to compilation with C++


Ranjit Mathew wrote:

On Wed, 14 Jul 2004 09:20:16 +0200, Paolo Bonzini <bonzini@gnu.org> wrote:

Much different, and much easier.  We may get rid of GNU extensions in
C++ so that it can be built in stage1.  Or, toplevel bootstrap will make
it significantly easier to provide a bootstrap target for people without
a C++ compiler, that does not build the Java front-end in stage2.

Either you're misunderstanding me or I am misunderstanding you. ;-)

What I meant was: why would a GCJ (Java) front-end in C++ be anything to cry hoarse over, when Ada already has a non-C front-end?

He does not misunderstand, he is saying that a GCJ front end in C++ is far less contentious from a build point of view than GNAT in Ada, where it is impossible to build native from native tools (it is in practice quite infeasible to build GNAT starting with another Ada compiler, although it was originally bootstrapped that way, and in any case, no one is going to buy an expensive proprietary Ada compiler to try to do this, cross-compilation is by far the easier rule.

There are really two issues here which are quite separate, and
it is helpful in this discussion to make it clear which you are
addressing.

1. Build issue. Currently g++ can be built starting with native
(non-GCC) tools. Is it acceptable to compromise this guarantee?
If you answer no, then use of C++ has to be restricted to optional
passes, or other front ends.

2. Language issue. These are about concerns with maintainability
of C++ code. These can be addressed by a rigorous set of coding
standards rigorously enforced. I think pretty much everyone
agrees with this generality. After all it is pretty much the
case that a strict enough set of coding standards gets you
back to C. But there is definitely some disagreement on the
definition of the coding standards (e.g. MI in or out?)

If you look at GNAT, you have a situation where the native Build
issue has not been addressed at all. The only way to get a GNAT
compiler onto a new architecture is by cross-compilation. The
language issue has been addressed by only allowing a very limited
set of functionality in the GNAT front end. The motivations for
these limitations are three-fold. First, to avoid excessive
complexity and the "going bananas" phenomenon, which is possible,
though more difficult than in C++. Second, to keep things simple
in the bootstrap debugging area. Third, to avoid the compiler
depending on a large complex run-time, which can cause bootstrap
path problems when this run-time and its interface is modified.

I agree with the latter part of your reply though: there will have to be a "stage4" where the newly built C++ compiler builds the Java front-end, if that's what you meant.

Ranjit.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]