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: Putting C++ code into gcc front end


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


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