This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Putting C++ code into gcc front end
- From: Zack Weinberg <zack at codesourcery dot com>
- To: tromey at redhat dot com
- Cc: GCC Hackers <gcc at gcc dot gnu dot org>
- Date: Mon, 03 Mar 2003 22:06:18 -0800
- Subject: Re: Putting C++ code into gcc front end
- References: <87of4rnc0c.fsf@fleche.redhat.com>
Tom Tromey <tromey at redhat dot com> writes:
> Recently I've some bugs in the gcj bytecode verifier. Historically
> the gcj verifier hasn't had many bug reports against it, but the newer
> Java compilers out there (specifically, the current jikes and the
> current Eclipse java compiler -- both free) generate code that it
> can't verify.
>
> Based on reading the gcj code (and my experience writing the runtime
> verifier), I think it would be easier, and cheaper in the long run, to
> re-use the libgcj bytecode verifier instead of trying to fix the bugs
> in the gcj one.
>
> It would be easier because the gcj verifier's approach to subroutines
> doesn't reflect the latest interpretations of the JVM spec. Changing
> this means redoing the most complicated part of the verifier. This
> part of the libgcj verifier is already well-debugged.
>
> It would be cheaper to do this in the long run because it would mean
> we'd only have to fix verifier bugs in one place. This would also
> make it easier to keep up with changes that are made to the spec (this
> does happen from time to time).
>
> However, the libgcj verifier is written in C++. So, if I were to do
> this, it would mean adding some C++ code to the gcj front end.
I have mixed feelings.
On the one hand I think that putting C++ into any part of the compiler
is a bad idea, because it will make bootstrapping more difficult --
even in this limited situation where C++ appears in none of the C
front end, the C++ front end, or the language-independent modules.
The C++ front end cannot be built in stage 1 due to its use of GNU
extensions to C; thus, starting from nothing but a non-GNU C compiler
one would have to do a four stage bootstrap. If libstdc++ has to get
involved (and it probably does, at least for the runtime support
routines) it's even worse -- one would have to build and install the
entire compiler with Java configured out, then come back and rebuild
with Java turned on.
On the other hand I recognize the utility of C++ for general coding
and I don't want to force you to do something harder than necessary.
And it is silly to have more than one bytecode verifier.
zw