Re: Bug 16115, C++ invisible references

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

On Wednesday 07 July 2004 00:33, Mark Mitchell wrote:
> I think this is a major policy point.  It may be something we should
> talk to the SC about, because it's a question of what we want GCC to be,
> as much as it is a technical question.  If GCC to be purely a compiler,
> then my argument has no validity.  If, on the other hand, we want G++ to
> be a separate front end that can be used for other purposes, then my
> argument has considerably more utility.

All would be much easier if you could go EDG-like all the way,
with a G++ specific (ie. non-tree) internal representation that
is very close to the source code, which can be lowered at a
later point (say, after parsing the whole file?) to the back-end
representation (ie. trees, but I'm sure LLVM and perhaps other
Free Software compilers).  Much like what Neil is doing in his
new C parser.  

I doubt any representation G++ produces now is useful for the
kind of non-compiler applications you have in mind, because the
trees and an occasional piece of RTL the front end produces are
purely aimed at g++-as-a-compiler.  Or at least, G++ could be
made much easier to work with for non-compiler applications, with
the bonus of no longer bloating the back end IR like G++ does now
with all those language specific trees and interesting ways in
which they're linked together.

Regardless of whether GCC must be more than purely a compiler
(IMO it should first try to be better at being just a compiler),
I believe going to truely language specific representations and
lighter weight trees would be a good idea.  GNAT and EDG are the
proof that it can be done ;-)

<PITA
If GCC should be more than purely a compiler, then surely dumping
the IR to a file should also no longer be an issue?  If we _want_
to make front ends usable by others, then that argument against
exporting the whole IR can be dropped ;-)
</PITA>

Gr.
Steven