Re: Putting C++ code into gcc front end

Re: Putting C++ code into gcc front end

[Benjamin Kosnik]

> The bottom line was: We should be able to use C++ where appropriate.

Too bad "be able" isn't the same as "free" here.

Even more to Tom's original point: it's a waste of valuable maintainer
time to re-write C++ bits in C. We are all too busy as it is: "C"
translation busy work is not helpful. It's not easy to do, some ideas
and code organization methods are hard or impossible to express in C,
the end result is sometimes a disappointment, and the situation then
becomes even more difficult to maintain with two separate versions in
two languages.

I think Richard Earnshaw has indicated the way forward here. Instead of
penalizing every gcc user with a modern compiler (the vast majority),
instead make the K&R folk do a pre-bootstrap stage-0 compiler. This
seems sane.

Next, the C++ front end converted to ISO C. Kaveh, Richard Earnshaw, and
Nathan seem to agree that this is possible.

Then, everything is cool.

-benjamin

Re: Putting C++ code into gcc front end

[Robert Dewar]

> May be it's because the Ada front-end has been ported to another backend
> for JGNAT (Java bytecode backend). This kind of effort forces its share
> of middle-end semantics cleanup. (I haven't got the time yet to look
> at the CLI/C# one).


Reasonable guess, but not at all real history. The JGNAT work involved very
few changes to the semantics, and what changes there are are defcinitely
not cleanups (well there are a few exceptions, but not many).

> IMO Ada has the best and cleanest GCC front end, despite being I think
> the biggest.  I wonder if the fact that it has its own representation
> is just a coincidence.


I don't know the other front ends well enough, and I know the GNAT front end
far too well, to make any comment on the first sentence, though we do put
a huge effort into keeping the code clean. I think the rigorous
adherence to the RM terminology and structure is very valuable.

Re: Putting C++ code into gcc front end

[Robert Dewar]

> > > Every front end should have it's own representation, which should be
> > > lowered to something common like GIMPLE that is simple, well-
> > > documented, and yet expressive enough to be useful to everyone.  I
> > > feel we can't make real progress any other way.  Imagine how
> > > maintainable each front-end having its own high-level IR with real
> > > distinct C structs and unions would be.

In the case of GNAT, the tree we use in the fr0ont end is precisely keyed to
the Ada standard. The strucure of the tree exactly matches that of the grammar
in the RM (one advantage of using a hand written parser that does not require
molestation of the grammar), and the internal nomenclature of this tree exactly
matches the usage of technical terms in the RM>

For us, that is far more important than aiming at commonality at that stage. We
looked early on at the idea of trying to be compatible in some sense with what
other front end were doing, but it was not seriously considered, since we have
found it *so* important to maintain faithfullness to the defining document
within the text of the compiler front end. The few places we have deviated from
it (for good reasons of course :-) have often been trouble spots.

Re: Putting C++ code into gcc front end

[Toon Moene]

Neil Booth wrote:

> Every front end should have it's own representation, which should be
> lowered to something common like GIMPLE that is simple, well-
> documented, and yet expressive enough to be useful to everyone.

Ah, you mean: like g95 :-)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: Putting C++ code into gcc front end

[Laurent Guerby]

On Sat, 2003-03-08 at 00:07, Neil Booth wrote:

> IMO Ada has the best and cleanest GCC front end, despite being I think
> the biggest.  I wonder if the fact that it has its own representation
> is just a coincidence.

May be it's because the Ada front-end has been ported to another backend
for JGNAT (Java bytecode backend). This kind of effort forces its share
of middle-end semantics cleanup. (I haven't got the time yet to look
at the CLI/C# one).

-- 
Laurent Guerby <guerby@acm.org>

Re: Putting C++ code into gcc front end

[Steven Bosscher]

Op za 08-03-2003, om 00:07 schreef Neil Booth:
> Geert Bosch wrote:-
> 
> > Note that Ada already builds its own tree for a complete
> > translation unit. As last action the root of this tree is
> > passed to "Gigi", which is the code that converts the GNAT
> > trees to GCC trees. However, even though this glue code is
> > very local, it is quite complex, and separation still isn't
> > quite complete. A better documented back end / front end
> > interface would be a great step forward.
> 
> IMO Ada has the best and cleanest GCC front end, despite being I think
> the biggest.  I wonder if the fact that it has its own representation
> is just a coincidence.

Well, of course having per-front end IRs gives you better separation
between the front end and the middle/back end, and you *may* just get a
cleaner front end if you design your new IR carefully..

But having your own representation is in itself not the Holy Grail
either.  Like Ada, G95 has its own internal representation.  The task of
translating it to another IR (GENERIC for G95) should not be
underestimated.  Like Geert said: That code is quite complex indeed.
(And I doubt even a million pages of documentation would change that.)

What I dislike most is that we go from one internal representation to
the next and there is no overlap between them: It's not like WHIRL where
you have five (?) different levels, but instead you go from a set of
front-end specific parse tree data structs to GENERIC, to GIMPLE, to
RTL.  These are completely different intermediate representations, only
GENERIC->GIMPLE is lowering, and even that step is almost a complete
rewrite in some bad cases.

Surely you would not want something like that in the C front end.

It is funny to see ipf-orc get away with front ends that build their
parse tree in their own IRs (most notably the GNU C/C++ front ends that
build trees) and then translate that to WHIRL.  And we're discussing
adding yet another intermediate representation that is nothing like what
we have now.  Yuck.

Greetz
Steven

Re: Putting C++ code into gcc front end

[law]

In message <Pine.LNX.4.21.0303071549550.2073-100000@mail.kloo.net>, tm_gccmail@
mail.kloo.net writes:
 >On Fri, 7 Mar 2003, Geoff Keating wrote:
 >
 >> Well... When I tried to imagine, I started thinking "and, yes, we
 >> could have completely different representations for exceptions and
 >> structures and references and function calls between the C, C++, Ada,
 >> and Java frontends" which didn't sound quite so great.  After all,
 >> another project which is also a good idea and not making much progress
 >> recently is to commonize more of the C and C++ frontends.
 >> 
 >> Maybe a better solution would be to document what the tree structure
 >> is actually supposed to look like, and then try to ensure that?
 >
 >Maybe an optional treechecking pass that ensures the sanity of the tree?
 >This way, the assumptions are automagically checked.
Part of the problem is writing that checking pass would be next to
impossible right now -- precisely because nobody knows all the little
ins and outs of how certain tree nodes/flags are used.

It's not unlike the situation we were in with RTL a couple years ago, it's
taken quite a white to identify all those little ins and outs of how each
RTL code & flag is used.

It's a lot of work.  ANd unlike RTL, there's lots of stuff that is 
specific to each front-end, which adds further complication.

Jeff

Re: Putting C++ code into gcc front end

[Neil Booth]

Geert Bosch wrote:-

> Note that Ada already builds its own tree for a complete
> translation unit. As last action the root of this tree is
> passed to "Gigi", which is the code that converts the GNAT
> trees to GCC trees. However, even though this glue code is
> very local, it is quite complex, and separation still isn't
> quite complete. A better documented back end / front end
> interface would be a great step forward.

IMO Ada has the best and cleanest GCC front end, despite being I think
the biggest.  I wonder if the fact that it has its own representation
is just a coincidence.

Neil.

Re: Putting C++ code into gcc front end

[Geert Bosch]

On Friday, Mar 7, 2003, at 17:50 America/New_York, Geoff Keating wrote:
>> Every front end should have it's own representation, which should be
>> lowered to something common like GIMPLE that is simple, well-
>> documented, and yet expressive enough to be useful to everyone.  I
>> feel we can't make real progress any other way.  Imagine how
>> maintainable each front-end having its own high-level IR with real
>> distinct C structs and unions would be.
>
> Well... When I tried to imagine, I started thinking "and, yes, we
> could have completely different representations for exceptions and
> structures and references and function calls between the C, C++, Ada, 
> and Java frontends" which didn't sound quite so great.
>
> After all, another project which is also a good idea
> and not making much progress recently is to commonize
> more of the C and C++ frontends.
>
> Maybe a better solution would be to document what the
> tree structure is actually supposed to look like,
> and then try to ensure that?

Note that Ada already builds its own tree for a complete
translation unit. As last action the root of this tree is
passed to "Gigi", which is the code that converts the GNAT
trees to GCC trees. However, even though this glue code is
very local, it is quite complex, and separation still isn't
quite complete. A better documented back end / front end
interface would be a great step forward.

   -Geert

Re: Putting C++ code into gcc front end

[Neil Booth]

Geoff Keating wrote:-

> > Every front end should have it's own representation, which should be
> > lowered to something common like GIMPLE that is simple, well-
> > documented, and yet expressive enough to be useful to everyone.  I
> > feel we can't make real progress any other way.  Imagine how
> > maintainable each front-end having its own high-level IR with real
> > distinct C structs and unions would be.
> 
> Well... When I tried to imagine, I started thinking "and, yes, we
> could have completely different representations for exceptions and
> structures and references and function calls between the C, C++, Ada,
> and Java frontends" which didn't sound quite so great.  After all,
> another project which is also a good idea and not making much progress
> recently is to commonize more of the C and C++ frontends.

Clearly things that are similar should have some kind of similar,
or common base specification.  But C++ has little in common with
Fortran; forcing them to use the same "stuff" as a high level
representation is clearly a loser.

IMO other telling signs of deep design problems is the middle
end telling the front end how to manage its symbol table: that's
basically what all the decl langhooks are about.

I think your point has more merit for a mid-level representation, like
I intimated in my post.

> Maybe a better solution would be to document what the tree structure
> is actually supposed to look like, and then try to ensure that?

I'm not willing to spend (a truly huge) amount of time on something I
don't think is the way forwards.  Particularly as I'm not being paid for
it.

Neil.

Re: Putting C++ code into gcc front end

[tm_gccmail]

On Fri, 7 Mar 2003, Geoff Keating wrote:

> Well... When I tried to imagine, I started thinking "and, yes, we
> could have completely different representations for exceptions and
> structures and references and function calls between the C, C++, Ada,
> and Java frontends" which didn't sound quite so great.  After all,
> another project which is also a good idea and not making much progress
> recently is to commonize more of the C and C++ frontends.
> 
> Maybe a better solution would be to document what the tree structure
> is actually supposed to look like, and then try to ensure that?

Maybe an optional treechecking pass that ensures the sanity of the tree?
This way, the assumptions are automagically checked.

Toshi

Re: Putting C++ code into gcc front end

[Geoff Keating]

> Date: Fri, 7 Mar 2003 22:20:21 +0000
> From: Neil Booth <neil@daikokuya.co.uk>

> It would be much easier if you didn't have to worry about 6 different
> front ends for every dinky little change you make to some tree.  Or
> if you had something that documented the quirks of how every field was
> used by every front end.  We have nothing close to that.  It's almost
> impossible to make significant changes to trees: not only do they
> represent everything, but they represent everything in every goddamn
> front end.  It's a really nasty situation to be in.
> 
> Every front end should have it's own representation, which should be
> lowered to something common like GIMPLE that is simple, well-
> documented, and yet expressive enough to be useful to everyone.  I
> feel we can't make real progress any other way.  Imagine how
> maintainable each front-end having its own high-level IR with real
> distinct C structs and unions would be.

Well... When I tried to imagine, I started thinking "and, yes, we
could have completely different representations for exceptions and
structures and references and function calls between the C, C++, Ada,
and Java frontends" which didn't sound quite so great.  After all,
another project which is also a good idea and not making much progress
recently is to commonize more of the C and C++ frontends.

Maybe a better solution would be to document what the tree structure
is actually supposed to look like, and then try to ensure that?

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Putting C++ code into gcc front end

[Neil Booth]

Geoff Keating wrote:-

> Yes, I completely agree.  In particular, we currently represent types
> and statements/expressions using trees, and I believe it's never the
> case that you can substitute one for the other (and what would that
> mean, anyway?); so why don't we have completely distinct type_tree and
> expr_tree data structures?
> 
> Of course, this has been mentioned several times before, and no-one's
> produced a patch...

I tried to do something far less ambitious: make all trees that point
to IDENTIFIER_NODEs only point to identifier nodes (and nothing else).
Believe me, that was so hard and messy I gave up.  And that's about
1% of the job.  I'm not surprised no-one's seen a patch.

It would be much easier if you didn't have to worry about 6 different
front ends for every dinky little change you make to some tree.  Or
if you had something that documented the quirks of how every field was
used by every front end.  We have nothing close to that.  It's almost
impossible to make significant changes to trees: not only do they
represent everything, but they represent everything in every goddamn
front end.  It's a really nasty situation to be in.

Every front end should have it's own representation, which should be
lowered to something common like GIMPLE that is simple, well-
documented, and yet expressive enough to be useful to everyone.  I
feel we can't make real progress any other way.  Imagine how
maintainable each front-end having its own high-level IR with real
distinct C structs and unions would be.

Neil.

Re: Putting C++ code into gcc front end

[Per Bothner]

Geoff Keating wrote:
> Yes, I completely agree.  In particular, we currently represent types
> and statements/expressions using trees, and I believe it's never the
> case that you can substitute one for the other (and what would that
> mean, anyway?); so why don't we have completely distinct type_tree and
> expr_tree data structures?

Agree in principle, but there are some complications.
For example decls can be expressions, which means expr_tree
and decl_tree have to be the same.  If you have "unresolved
identifier" in the tree, then identifier has to be an expr_tree.

You can solve both of these cleanly by adding a DECL_REFERENCE
expression type.

 > Of course, this has been mentioned several times before, and no-one's
 > produced a patch...

Is there a way to make this change incrementally, such that
you could use type_tree in a variable or parameter declaration,
without having to fix everywhere at once?  Of course C++ would
make that too easier ...  For C, I can't think of any way,
except making type_tree just be a typedef for tree, which might
still be worthwhile for documentation purposes.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Putting C++ code into gcc front end

[Geoff Keating]

Neil Booth <neil@daikokuya.co.uk> writes:

> Pop S?bastian wrote:-
> 
> > On Thu, Mar 06, 2003 at 05:53:42PM -0800, Per Bothner wrote:
> > > Personally, I'd love to re-write all of Gcc in C++,
> > > starting with using inheritance for tree nodes, so
> > > we can actually get some static type-checking.
> 
> Really, why does everything have to be shoehorned into being a tree?
> Decls, expressions, scopes / symbol tables, statements etc should
> all be their own data type.  We can get perfectly good type checking
> in C if we don't insist the universe is made up of trees.
> 
> cpplib hasn't made everything a tree.  There's no reason for everything
> to be a tree in the front ends either.

Yes, I completely agree.  In particular, we currently represent types
and statements/expressions using trees, and I believe it's never the
case that you can substitute one for the other (and what would that
mean, anyway?); so why don't we have completely distinct type_tree and
expr_tree data structures?

Of course, this has been mentioned several times before, and no-one's
produced a patch...

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Putting C++ code into gcc front end

[Per Bothner]

Neil Booth wrote:
> Really, why does everything have to be shoehorned into being a tree?
> Decls, expressions, scopes / symbol tables, statements etc should
> all be their own data type.  We can get perfectly good type checking
> in C if we don't insist the universe is made up of trees.

I agree.  However, inheritance is still useful.  For example
one might have different classes for different kinds of
declarations, different kinds of expressions, etc.  Perhaps
not that big a benefit.

Even more valuable: C++ constructors, destructors, and assignment
operators might have reduced the need for garbage collection.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Putting C++ code into gcc front end

[Neil Booth]

Pop S?bastian wrote:-

> On Thu, Mar 06, 2003 at 05:53:42PM -0800, Per Bothner wrote:
> > Personally, I'd love to re-write all of Gcc in C++,
> > starting with using inheritance for tree nodes, so
> > we can actually get some static type-checking.

Really, why does everything have to be shoehorned into being a tree?
Decls, expressions, scopes / symbol tables, statements etc should
all be their own data type.  We can get perfectly good type checking
in C if we don't insist the universe is made up of trees.

cpplib hasn't made everything a tree.  There's no reason for everything
to be a tree in the front ends either.

Neil.

Re: Putting C++ code into gcc front end

[Joseph S. Myers]

On Thu, 6 Mar 2003, Per Bothner wrote:

> Personally, I'd love to re-write all of Gcc in C++,
> starting with using inheritance for tree nodes, so
> we can actually get some static type-checking.

You don't need C++ to get some static type checking; in general,
declarations, expressions, types and identifiers could have their own
static types, since most of the code expects just one of these.  (I doubt
the benefit of the common generic "tree" type that covers all of these.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Putting C++ code into gcc front end

[Toon Moene]

Richard Earnshaw wrote:

>>Well, for new hosts, we can use a cross-compiler on an established host to
>>start the bootstrapping.
>>That way, we need no pre-existing compiler on the new system.
> 
> 
> *IF* you don't need proprietary tools on the target to produce your image.

Talking about proprietary, I read on Slashdot that C++ is owned by SCO.

Perhaps it's better to switch to an honest-to-God IBM-developed 
language: <a href="http://www.fortran.com/ibm2.jpg">Fortran</a>.

Oh, I almost forgot:

       IMPLICIT SMILEY (A-Z)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: Putting C++ code into gcc front end

[Pop Sébastian]

On Thu, Mar 06, 2003 at 05:53:42PM -0800, Per Bothner wrote:
> Personally, I'd love to re-write all of Gcc in C++,
> starting with using inheritance for tree nodes, so
> we can actually get some static type-checking.

I also think we could win in this rewriting. 

I already started to work in this direction and the first step 
would be to provide an interface for building the underlying 
structures.

For the tree level the interface would be something like:
- a build_<lang>_* interface for language specific trees
- a build_generic_* interface for building GENERIC trees
- a build_gimple_* interface for building GIMPLE trees

http://gcc.gnu.org/ml/gcc/2002-09/msg01036.html

Once we removed all the dependencies on the structures via an 
appropriate interface, we're ready to switch to a better 
implementation. 

Since this interfacing work is quite intrusive (it will affect 
all the "build (" or "build1 (" functions), I would like it to go 
in the mainline instead of in a branch.  A new branch will contain 
the oo-trees that will (I hope) replace the current tree structures. 
The performances in compile time and the clarity of the design (this 
includes the documentation) will decide of the inclusion of this 
branch in mainline.  

	Sebastian

Re: Putting C++ code into gcc front end

[Per Bothner]

Personally, I'd love to re-write all of Gcc in C++,
starting with using inheritance for tree nodes, so
we can actually get some static type-checking.
I don't think the issue of the people not having
C++ compilers is as important as developer convenience
and building a solid compiler:  I believe there are very
few people that have a C compiler but don't have or can't
easily get a C++ compiler.

I also think it would be very nice to combine the
two verifiers - it's a complicated algorithm, difficult
to get right, and there are lots of checks that one
or the other misses.

However, there are complications.  One problem is that
the data types are incompatible:  The compile-time
verifier uses treea, the run-time verifier uses run-time
classes and other data structures.  This difference
will presumably have to be hidden using macros or
conditional compilation.  (Compare the way jcf-reader.c
abstracts away what to do with the information read from
a .class file.)  A lot of the logic of the two verifiers
(i.e. big switch on opcodes) is similar; a large part of
the difference is the data structures - plus how we handle
the hard bits relating to subroutines.

I'm not sure the abstraction advantages of C++ helps all
that much.  The compile-time verifier is substanially
less code than the run-time verifier, though comments
some up some of the difference.  Given that both are
incomplete and have bugs (probably more in the compile-time
verifier) it's impossible to make a real comparison.

If I was doing the work, and I understood the issues and
existing code better than I do, I would replace the
subroutine-handling code in the compile-time verifier
with C code based on the algorithms and data structures
in the run-time verifier, and also merge in other missing
tests from the latter.  Then I'd hide the API (such of trees
etc) behind macros, and try plugging it into run-time
verifier.

However, that's a fair bit of work.  I think plugging the
run-time verifier into the compile-time environment *plus*
changing the boostrap framework so gcc/java can contain C++
code is also a fair bit of work.  I'll give my blessing
either way - if we can achieve consensus that using C++
in gcc/java is ok.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Putting C++ code into gcc front end

[Michael Matz]

Hi,

On 6 Mar 2003, Gabriel Dos Reis wrote:

> |                                                           If we need a
> | list or map in the compiler I never would use the STL, and instead write
> | something simple by hand.
>
> I agree with this, but only for if we were to write the C++ front-end
> in C++.
>
> For other other front-ends, the right fix is, IMHO, to improve GCC's
> ability to reduce abstraction penalty.

No, I meant the compile time, not code quality.  Compiling sources
including STL headers simply takes much time.  That you have to pay an
abstraction penalty is another issue, and indeed this needs to be fixed
also.


Ciao,
Michael.

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

|                                                           If we need a
| list or map in the compiler I never would use the STL, and instead write
| something simple by hand.

I agree with this, but only for if we were to write the C++ front-end
in C++.

For other other front-ends, the right fix is, IMHO, to improve GCC's
ability to reduce abstraction penalty.

-- Gaby

Re: Putting C++ code into gcc front end

[Karel Gardas]

On Thu, 6 Mar 2003, Michael Matz wrote:

> > It means you can't use iostreams, since they are templates.  You can't
> > use strings either.  You can't use any of the *very* convenient
> > features of the Standard Template Library.
>
> But if the reason is, that we want to use the STL, I would be quite
> strongly against that.  Using STL anywhere, even the simpler classes, has
> a such huge impact on compile time, that it's not funny.  If we need a
> list or map in the compiler I never would use the STL, and instead write
> something simple by hand.  All the hooks and possibilities STL provides
> make it extremely slow to compile.

Oops, that would be good, since then you will see how g++ is slow and you
will search for all posibilities how to make it faster. I think all g++
users will appreciate such work :-)

Sorry, just kidding...

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: Putting C++ code into gcc front end

[Michael Matz]

Hi,

On 6 Mar 2003, Alexandre Oliva wrote:

> > In particular I would certainly
> > favor a rule forbidding the use of templates,
>
> This would be silly.

To this I agree.  templates in it's simpler forms are portable.

> It means you can't use iostreams, since they are templates.  You can't
> use strings either.  You can't use any of the *very* convenient
> features of the Standard Template Library.

But if the reason is, that we want to use the STL, I would be quite
strongly against that.  Using STL anywhere, even the simpler classes, has
a such huge impact on compile time, that it's not funny.  If we need a
list or map in the compiler I never would use the STL, and instead write
something simple by hand.  All the hooks and possibilities STL provides
make it extremely slow to compile.

> C++ without templates misses a lot of the benefits.  C++ without
> templates is kinda sorta a bit like C without pointers :-)

Well, yes.  But C++ without STL has only advantages except for throw away
programs, which have to be written fast (like in a programming contest ;-)
)

All IMHO.


Ciao,
Michael.

Re: Putting C++ code into gcc front end

[Nathanael Nerode]

Tim Josling said:

>At the moment, to hack GCC, you need to know
>
>sh
>make
>configure
>cygnus-configure
Not anymore -- I killed it. :-)

--Nathanael

Re: Putting C++ code into gcc front end

[Tim Josling]

I mostly don't include C++ in the bootstrap, because

a) It takes twice as long. Sometimes that's the difference between midnight
and 1AM.
b) I don't like C++ (just my personal opinion).

At the moment, to hack GCC, you need to know

sh
make
configure
cygnus-configure
m4
C
tcl
expect
dejagnu
rtl
spec
autoconf
autogen
(more than that, I am sure)
sed
'lex'
'yacc'

I think that's enough. Please don't add C++. I am hoping it will go away
before I need to learn it. )On the positive side, longer builds would give me
time to learn it ;-))

Tim Josling

>   From: 
>        Michael Matz
> 
> Hi,
> 
> On 3 Mar 2003, Tom Tromey wrote:
> 
> > 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.
> >
> > In case it matters, the C++ code in question is in gcc/libjava/verify.cc.
> 
> Regarding the use of C++ in the non-{C,C++} frontends I'm undecided.  But
> if something like verify.cc gets into bootstrap process, we somewhen need
> to speed up the compiler.  verify.cc and interpret.cc are two of the most
> time suckers in compiling the compiler generally and libjava especially.
> I wouldn't like to have this code compiled three times.
> 
> 
> Ciao,
> Michael.

Re: Putting C++ code into gcc front end

[Richard Earnshaw]

> > > > Just at this point it isn't reasonable to assume that there
> > > > are conforming (even sufficiently conforming) C++ compilers widely
> > > > available on the wide range of hosts that GCC currently supports.
> > > > There is gcc 3.2.2.
> >
> > But that doesn't support hosts that might come along in the future (or are
> > you proposing to maintain it in perpetuity?)
> 
> Well, for new hosts, we can use a cross-compiler on an established host to
> start the bootstrapping.
> That way, we need no pre-existing compiler on the new system.

*IF* you don't need proprietary tools on the target to produce your image.

R.

Re: Putting C++ code into gcc front end

[Alexandre Oliva]

On Mar  5, 2003, Zack Weinberg <zack@codesourcery.com> wrote:

> My concern is entirely about *where* C++ can safely be used,
> and my opinion at the present time is "only in front ends other than
> C/C++/Ada."

I believe we should also let C++ into optional optimization passes.
The key here is `optional'.  As long as there's a way to build a
feature-limited C++ front-end starting with a random ISO C90 (or maybe
with the current GCC), that could then be used to build a
fully-optimizing compiler (at the expense of an additional stage),
we're ok.

> We can *not* easily ask everyone who currently
> builds GCC to install a C++ compiler for bootstrap purposes.

This is really not entirely different from Ada, except that, in my
proposal, it would be better than Ada.  Without GNAT, you just can't
build GNAT at all.  If we start using C++ in front-ends, even in
machine-independent code, as long as it's an optional part of the
build, we can get to a fully functional C/C++/etc compiler starting
out with a C-only compiler.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Putting C++ code into gcc front end

[Alexandre Oliva]

On Mar  5, 2003, dewar@gnat.com (Robert Dewar) wrote:

> In particular I would certainly
> favor a rule forbidding the use of templates,

This would be silly.  It means you can't use iostreams, since they are
templates.  You can't use strings either.  You can't use any of the
*very* convenient features of the Standard Template Library.  C++
without templates misses a lot of the benefits.  C++ without templates
is kinda sorta a bit like C without pointers :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Putting C++ code into gcc front end

[Joern Rennecke]

> > > Just at this point it isn't reasonable to assume that there
> > > are conforming (even sufficiently conforming) C++ compilers widely
> > > available on the wide range of hosts that GCC currently supports.
> > > There is gcc 3.2.2.
>
> But that doesn't support hosts that might come along in the future (or are
> you proposing to maintain it in perpetuity?)

Well, for new hosts, we can use a cross-compiler on an established host to
start the bootstrapping.
That way, we need no pre-existing compiler on the new system.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: Putting C++ code into gcc front end

[Fergus Henderson]

On 04-Mar-2003, Tom Tromey <tromey@redhat.com> wrote:
> For instance, the libgcj verifier assumes it can throw an exception
> from just about anywhere to indicate a failure.  Porting this to C
> would mean a major revamp of all the control throw (or the use of
> longjmp, I suppose).

You could use "CXCPT", my C-compatible exception library, which
is a wrapper around either longjmp() or C++ exceptions.  See
<http://gcc.gnu.org/ml/gcc/2002-04/msg00000.html>

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: Putting C++ code into gcc front end

[Andrew Haley]

Karel Gardas writes:
 > On Wed, 5 Mar 2003 tm_gccmail@mail.kloo.net wrote:
 > 
 > > I personally think having parts of GCC written in C++ is a bad idea,
 > > as it forces people to know Yet Another Language in addition to
 > > C, shell scripts, sed, makefiles, etc.
 > >
 > > However, if this happens, you might consider looking at Mozilla's
 > > C++ coding guidelines - they have experience with compiling with
 > > many different C++ compilers on many different platforms.
 > >
 > > Here's the URL:
 > >
 > > http://www.mozilla.org/hacking/portable-cpp.html
 > 
 > First five points on this list look quite restrictive:
 > 
 > - Don't use C++ templates.
 > - Don't use static constructors.
 > - Don't use exceptions.
 > - Don't use Run-time Type Information.
 > - Don't use namespace facility.

And rather old-fashioned.

We are compiler writers.  We are not ignorant users.  We should know
which features are expensive, and which are not.  We should know which
features make code easier to read, and which make it harder.

If we use templates, it is because we know why we are using them, and
it is the best way to solve the problem at hand.

If someone submits a patch that is inefficient or difficult to read,
that patch should be rejected.  We already have mechanisms in place to
control this problem.

Trust the maintainers.

Andrew.

Re: Putting C++ code into gcc front end

[Vladimir Merzliakov]

>
>   You can also lookat the speed of mozilla, people are using other
> browsers because it's SLOW , I'd hate to see gcc slow to a crawl :-(
>

It's not C++ problem. Gecko HTML engine (used by mozilla) writed in C++ also
and used

in many other browsers and it vary fast.

Mozilla GUI is slow indeed.

Vladimir

Re: Putting C++ code into gcc front end

[Richard Earnshaw]

> Everyone in this discussion is talking about *which* C++ features
> should be allowed, which is orthogonal to my original concern on this
> score.  My concern is entirely about *where* C++ can safely be used,
> and my opinion at the present time is "only in front ends other than
> C/C++/Ada."  We can easily arrange to have a fully functional g++ and
> libstdc++ available when those front ends are built, starting with
> only a C compiler.  We can *not* easily ask everyone who currently
> builds GCC to install a C++ compiler for bootstrap purposes.  I am
> personally familiar with an organization that still uses gcc 2.7.2 as
> a starting point for GCC builds.  That's a bit extreme, but still.

That's my opinion too.

R.

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Karel Gardas <kgardas@objectsecurity.com> writes:

| I agree that some template code might looks unreadable although templates
| are very usable, on the other hand my main complain of this list was
| about:
| 
| - Don't use exceptions.

I don't believe that was being considered as a constraint for use in
Java front-end.

-- Gaby

Re: Putting C++ code into gcc front end

[Olivier Galibert]

On Wed, Mar 05, 2003 at 02:12:31PM -0800, Zack Weinberg wrote:
> We can *not* easily ask everyone who currently
> builds GCC to install a C++ compiler for bootstrap purposes.  I am
> personally familiar with an organization that still uses gcc 2.7.2 as
> a starting point for GCC builds.  That's a bit extreme, but still.

They have two easy solutions:
- use the 3.x g++ compiler they bootstrapped from their 2.7.2 ages ago
- find binaries on the net
- pay [insert gcc vendor here, that even includes the fsf iirc] to
  provide them with binaries

Gcc maintainer time is finite, very finite, and if some C++ features
helps them doing their jobs (like full-on abstration or exceptions in
the verify.cc case), should their time and convenience be second to
unnamed organizations?

If you ever compared a gtk+ to a Qt equivalent program, you already
know how crappy and unmaitainable simulated object in C can be.  And,
as emacs proves, exceptions through setjmp/longjmp are better left to
compilers to generate.  Do you want to see that kind of crap appear in
gcc, especially in the backend?

  OG.

Re: Putting C++ code into gcc front end

[Lars Segerlund]

  You can also lookat the speed of mozilla, people are using other 
browsers because it's SLOW , I'd hate to see gcc slow to a crawl :-(

  / Lars Segerlund.

tm_gccmail@mail.kloo.net wrote:
> On Wed, 5 Mar 2003, Robert Dewar wrote:
> 
..snip...
> 
> I personally think having parts of GCC written in C++ is a bad idea,
> as it forces people to know Yet Another Language in addition to
> C, shell scripts, sed, makefiles, etc.
> 
> However, if this happens, you might consider looking at Mozilla's
> C++ coding guidelines - they have experience with compiling with
> many different C++ compilers on many different platforms.
> 
> Here's the URL:
> 
> http://www.mozilla.org/hacking/portable-cpp.html
> 
> Toshi
> 
> 
> 
> 

Re: Putting C++ code into gcc front end

[Karel Gardas]

On Wed, 5 Mar 2003, Robert Dewar wrote:

> > First five points on this list look quite restrictive
>
> Well "quite restrictive" is not necessarily a bad thing. In particular I would certainly
> favor a rule forbidding the use of templates, because the use of templates can so easily
> get out of hand. Perhaps someone who knows C++ better than I do can formulate rules to
> prevent misuse of templates, but I often see C++ code where the authors seem completely
> fearless when it comes to using the language in a very complex unreadable manner. If we
> let that kind of code in, we are behind, not ahead of the current state of things.
>

I agree that some template code might looks unreadable although templates
are very usable, on the other hand my main complain of this list was
about:

- Don't use exceptions.

since IIRC Tom requires it for his port of libjava verify.cc to java
front-end verify.c

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > First five points on this list look quite restrictive
| 
| Well "quite restrictive" is not necessarily a bad thing. In
| particular I would certainly 
| favor a rule forbidding the use of templates, because the use of
| templates can so easily 
| get out of hand.

The same may be said for virtually everything else in C.

However, yes, some advanced template constructs need better compilers.
But that does not mean that every template construct is advanced.
No.  That does not reflect reality.

Certainly, I don't want to implement the same data structure in C++
each time the contained objet type changes.


   template<class T>
     struct list {
         list<T>* previous;
         list<T>* next;
         T        data;
     };

will work even with GCC-2.7.x.  It is -not- an advanced construct.
It has been in ARM C++.

| Perhaps someone who knows C++ better than I do can
| formulate rules to prevent misuse of templates,

Matt gave some thoughts on that issue.

Anyway, this is completely orthogonal to Tom's request.

-- Gaby

Re: Putting C++ code into gcc front end

[Robert Dewar]

> First five points on this list look quite restrictive

Well "quite restrictive" is not necessarily a bad thing. In particular I would certainly
favor a rule forbidding the use of templates, because the use of templates can so easily
get out of hand. Perhaps someone who knows C++ better than I do can formulate rules to
prevent misuse of templates, but I often see C++ code where the authors seem completely
fearless when it comes to using the language in a very complex unreadable manner. If we
let that kind of code in, we are behind, not ahead of the current state of things.

Re: Putting C++ code into gcc front end

[Chris Lattner]

Karel Gardas wrote:
> On Wed, 5 Mar 2003 tm_gccmail at mail dot kloo dot net wrote:
>> I personally think having parts of GCC written in C++ is a bad idea,
>> as it forces people to know Yet Another Language in addition to
>> C, shell scripts, sed, makefiles, etc.

Not that it matters, but I'm highly in favor of using C++ in GCC...

> First five points on this list look quite restrictive:
> - Don't use C++ templates.
> - Don't use static constructors.
> - Don't use exceptions.
> - Don't use Run-time Type Information.
> - Don't use namespace facility.

Note that following this list is an extremely bad idea.  They intended to
support extremely old compilers.  I believe they even tried to support
Visual C++ 1.52 or something thereabouts.  This is an OLD compiler.

For some reflection on these guidelines, please take a look at:
http://www.mozilla.org/hacking/cpp_portability/mozilla_decisions.html

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

Re: Putting C++ code into gcc front end

[Zack Weinberg]

Benjamin Kosnik <bkoz@redhat.com> writes:

>> I think the only really controversial question would be whether to allow
>> partial specialization of templates. Everything else is a clear yes or a
>> clear no.
>
> Please, let's stay on topic. Tom has requested, and has a valid need for:
>
> 1) full C++ class semantics, including construction/destruction
> 2) exception handling
>
> I don't think it's necessary to debate that these requests are
> reasonable, nor do I think it is necessary to define at this moment what
> is acceptable use, now or in the future: that's for maintainers in the
> future to deal with. These kind of limitations are precisely what has
> put this whole question on the table.

Everyone in this discussion is talking about *which* C++ features
should be allowed, which is orthogonal to my original concern on this
score.  My concern is entirely about *where* C++ can safely be used,
and my opinion at the present time is "only in front ends other than
C/C++/Ada."  We can easily arrange to have a fully functional g++ and
libstdc++ available when those front ends are built, starting with
only a C compiler.  We can *not* easily ask everyone who currently
builds GCC to install a C++ compiler for bootstrap purposes.  I am
personally familiar with an organization that still uses gcc 2.7.2 as
a starting point for GCC builds.  That's a bit extreme, but still.

zw

Re: Putting C++ code into gcc front end

[Karel Gardas]

On Wed, 5 Mar 2003 tm_gccmail@mail.kloo.net wrote:

> I personally think having parts of GCC written in C++ is a bad idea,
> as it forces people to know Yet Another Language in addition to
> C, shell scripts, sed, makefiles, etc.
>
> However, if this happens, you might consider looking at Mozilla's
> C++ coding guidelines - they have experience with compiling with
> many different C++ compilers on many different platforms.
>
> Here's the URL:
>
> http://www.mozilla.org/hacking/portable-cpp.html

First five points on this list look quite restrictive:

- Don't use C++ templates.
- Don't use static constructors.
- Don't use exceptions.
- Don't use Run-time Type Information.
- Don't use namespace facility.

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: Putting C++ code into gcc front end

[Fabio Alemagna]

On Wed, 5 Mar 2003 tm_gccmail@mail.kloo.net wrote:
> I personally think having parts of GCC written in C++ is a bad idea,
> as it forces people to know Yet Another Language in addition to
> C, shell scripts, sed, makefiles, etc.

Often it's easier to learn YAL rather than trying to understand code which
is in a bad shape due to the fact that the proper language wasn't used.

I'm sorry to say that the latter is the gcc's case in many parts of it.

Fabio Alemagna

Re: Putting C++ code into gcc front end

[tm_gccmail]

On Wed, 5 Mar 2003, Robert Dewar wrote:

> >   * there is a well-formed  corpus of C++ well-implemented by
> >     compilers out there.  That corpus is the not the most recent
> >     innovative features of the langage but successful projects in C++
> >     don't always use the most recent features.
> 
> So perhaps the prerequisite here is to develop an agreed set of language features
> that can be used, chosen with two goals in mind:
> 
> 1. Keep the code clear, and accessible by non-C++ experts
> 
> 2. Keep the code compilable by a wide range of C++ compilers

I personally think having parts of GCC written in C++ is a bad idea,
as it forces people to know Yet Another Language in addition to
C, shell scripts, sed, makefiles, etc.

However, if this happens, you might consider looking at Mozilla's
C++ coding guidelines - they have experience with compiling with
many different C++ compilers on many different platforms.

Here's the URL:

http://www.mozilla.org/hacking/portable-cpp.html

Toshi

Re: Putting C++ code into gcc front end

[Toon Moene]

Matt Austern wrote:

> On Wednesday, March 5, 2003, at 07:58 AM, Gabriel Dos Reis wrote:

>> dewar@gnat.com (Robert Dewar) writes:

>> | 1. Keep the code clear, and accessible by non-C++ experts
>> |
>> | 2. Keep the code compilable by a wide range of C++ compilers
>>
>> Absolutely.

> I think the only really controversial question would be whether to allow 
> partial specialization of templates.  Everything else is a clear yes or 
> a clear no.

Hmmm, I'd like to propose a *restrictive* list: Only constructs that are 
explained in Koenig and Moo's "Accelerated C++" are allowed (at least 
that book isn't much thicker than the New Testament).

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: Putting C++ code into gcc front end

[Benjamin Kosnik]

> I think the only really controversial question would be whether to allow
> partial specialization of templates. Everything else is a clear yes or a
> clear no.

Please, let's stay on topic. Tom has requested, and has a valid need for:

1) full C++ class semantics, including construction/destruction
2) exception handling

I don't think it's necessary to debate that these requests are
reasonable, nor do I think it is necessary to define at this moment what
is acceptable use, now or in the future: that's for maintainers in the
future to deal with. These kind of limitations are precisely what has
put this whole question on the table.

-benjamin

ps. thanks mark for letting the rest of us know that the SC is
contemplating this issue. I propose "oracle@gcc.gnu.org" for the rest of
us to ask the SC questions.

Re: Putting C++ code into gcc front end

[Mike Stump]

On Tuesday, March 4, 2003, at 11:16 PM, Gabriel Dos Reis wrote:
> Zack Weinberg <zack@codesourcery.com> writes:
> | | C++ compilers and runtime libraries that implement the full 
> language
> | as it was standardized are still rare.  Compilers that implement a
> | language called "C++" that is incompatible with standard C++ are 
> still
> | common.
>
> I think that is too negative to reflect reality.

As do I.  g++ can be ported to almost any machine that needs to have 
C++, or already has been.  g++ put simply, is widely available.  It is 
usually no less widely available than gcc.  You can take a poll, but I 
suspect you'll find that 99.99% of our users _can_ use gcc/g++ to 
compile gcc.  Now, the question is how much pain and suffering should 
the other 0.01% cause us, the FSF answer is, they exist at our 
pleasure.  You may have a different opinion.

Also, we tend to focus on distributors more than end-users, and 
distributors I don't think are put off by having to have gcc/g++ to 
build.  Most users tend to take up the compiler with binary packages, 
in this case, the issue is very moot, as it is the same exact command 
to them either way.  The most major impact for them would be, we would 
need a stable libstdc++.so that won't break and cause the compilers to 
become non-functional.

Re: Putting C++ code into gcc front end

[Matt Austern]

On Wednesday, March 5, 2003, at 07:58 AM, Gabriel Dos Reis wrote:

> dewar@gnat.com (Robert Dewar) writes:
>
> | So perhaps the prerequisite here is to develop an agreed set of 
> language features
> | that can be used, chosen with two goals in mind:
> |
> | 1. Keep the code clear, and accessible by non-C++ experts
> |
> | 2. Keep the code compilable by a wide range of C++ compilers
>
> Absolutely.

I think the only really controversial question would be whether to 
allow partial specialization of templates.  Everything else is a clear 
yes or a clear no.

			--Matt

Re: Putting C++ code into gcc front end

[Mark Mitchell]

On Wed, 2003-03-05 at 01:40, Joseph S. Myers wrote:
> On 4 Mar 2003, Steven Bosscher wrote:
> 
> > I believe that the answer was: "Yes, because we have exactly one
> > platform that does not come with an ISO C compiler (HPUX).  We will look
> > at this issue again in the 3.4 time frame".

The SC is presently debating that issue.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Putting C++ code into gcc front end

[Dale Johannesen]

On Wednesday, March 5, 2003, at 08:23  AM, Marc Espie wrote:
> In article <6997EA81-4E6A-11D7-80F3-000393D76DAA@apple.com> you write:
>> If you really want to be compliant, all external names have to be 
>> unique
>> within 6 characters, case-insensitive (3.1.2).  Somehow I doubt that's
>> going to happen.
>
> On the contrary, this is really easy to do. Just run nm, cut at six 
> chars,
> look at collisions. Then add an includ at config.h level which 
> correctly
> mangles the names to avoid collisions if wanted.

Actually, I didn't say it wasn't easy to do, I just doubted it would 
happen.
(And maintaining your scheme correctly over time seems even less 
likely.)
There's no real reason to IMO; long names have been portable (although
not standard) since I started writing in C in the mid-80s.  I know of no
current environment that needs this restriction (obviously, none that
gcc currently builds in has it).

Re: Putting C++ code into gcc front end

[Marc Espie]

In article <6997EA81-4E6A-11D7-80F3-000393D76DAA@apple.com> you write:
>If you really want to be compliant, all external names have to be unique
>within 6 characters, case-insensitive (3.1.2).  Somehow I doubt that's 
>going to happen.

On the contrary, this is really easy to do. Just run nm, cut at six chars,
look at collisions. Then add an includ at config.h level which correctly
mangles the names to avoid collisions if wanted.

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| So perhaps the prerequisite here is to develop an agreed set of language features
| that can be used, chosen with two goals in mind:
| 
| 1. Keep the code clear, and accessible by non-C++ experts
| 
| 2. Keep the code compilable by a wide range of C++ compilers

Absolutely.

-- Gaby

Re: Putting C++ code into gcc front end

[Robert Dewar]

>   * there is a well-formed  corpus of C++ well-implemented by
>     compilers out there.  That corpus is the not the most recent
>     innovative features of the langage but successful projects in C++
>     don't always use the most recent features.

So perhaps the prerequisite here is to develop an agreed set of language features
that can be used, chosen with two goals in mind:

1. Keep the code clear, and accessible by non-C++ experts

2. Keep the code compilable by a wide range of C++ compilers

Re: Putting C++ code into gcc front end

[Joseph S. Myers]

On 4 Mar 2003, Steven Bosscher wrote:

> I believe that the answer was: "Yes, because we have exactly one
> platform that does not come with an ISO C compiler (HPUX).  We will look
> at this issue again in the 3.4 time frame".

The SC stated <http://gcc.gnu.org/ml/gcc/2002-06/msg00871.html> that they
intended to revisit the issue for 3.3 (where what was referred to then as
3.3 is what is now 3.4).  So I hope there will be a statement about the
decision for 3.4 from the SC soon.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Putting C++ code into gcc front end

[Tom Lord]

Aside from all the more pressing issues yr dealing with, I think it'd
be a swell idea to work towards maintaining a bootstrap path from raw
iron to GCC that doesn't depend on either old versions of GCC or
proprietary compilers.   And there's actually a potential day-to-day
practical benefit from doing so.

Supposing one does something like:

	forthish -> text/shell-utilish -> tiny fast CC -> GCC

the tiny, fast, GCC (and yes, there are several current candidates for
that stage, though some of the best have problematic licenses) can
have the practical use of being GCC-compatible and relentlessly
trading quality of generated code for raw compilation speed (but with
at least some GNUC extensions).   Why gosh, such a compiler would
likely have some useful IDE applications.

As a side effect, you'd have a permanent, clean, alterntative to
worrying about things like K&R bootstrapping paths and the like.

Ya know?

"but then again, I guess I'm just weird that way",
-t

Re: Putting C++ code into gcc front end

[Lars Segerlund]

  So now we don't have a problem at all with bootstrap time ?

  Compile/bootstrap time is a real issue for a lot of people working 
with gcc & friends.

  This relating to bootstraping more code is good ....

  / Lars Segerlund.

Michael Matz wrote:
> Hi,
> 
> On Tue, 4 Mar 2003, Benjamin Kosnik wrote:
> 
> 
>>>what if we only built the C front end, optimizers, and back end during
>>>all three stages of a bootstrap?  And then came back to build the other
>>>front ends when we were done?
>>
>>I think this sounds like a really good idea.
> 
> 
> No, it's not.  Of course it depends on which parts you're interested.
> But for me, bootstrapping more source is better than fewer for reasons
> given in another mail from me.  Building the compilers actually doesn't
> take that much more time.  Surely less time than libstdc++ and libjava.
> 
> 
> Ciao,
> Michael.
> 
> 

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| dewar@gnat.com (Robert Dewar) writes:
| 
| > Seriously, I think it is reasonable at this stage to admit C++ more
| > widely. Yes, it may complicate build processes a bit, but gcc is a
| > huge complex program, and anything that can make it easier to manage
| > such a large program by improving abstraction seems a clear win to me.
| 
| C++ compilers and runtime libraries that implement the full language
| as it was standardized are still rare.  Compilers that implement a
| language called "C++" that is incompatible with standard C++ are still
| common.

I think that is too negative to reflect reality.  

Certainly compilers out there vary in what they implement of the
recent template technology, but:

  * We don't need the full language and full runtime support (in
    effect, G++ was notorously known not to implement the full
    language nor to have a full implementation of the library nor to
    have a correect implementation of the language, still it was, is
    and will coontinue to be widely used);  
 
  * C++ is not reduced to templates;

  * even from the templates, there is a fair core that has been stable
    for a decade -- even GCC-2.7.x supports basic template constructs;

  * there is a well-formed  corpus of C++ well-implemented by
    compilers out there.  That corpus is the not the most recent
    innovative features of the langage but successful projects in C++
    don't always use the most recent features.

There are lots of successul C++ projects out there, and they are not
experimental ones.

CFront was written in C++, and at the time C90 compilers were not as
comon as today.  Still I can't say there was so much Fear,
Uncertainty and Doubt about C++ use as an implementation language
to impmlement CFront.

Let's get rid of the Fear, Uncertainty and Doubt spread out by the
urban legend and acknowledge the fact that C++ can be used to
implement efficiently major parts of something as complex as a
compiler collection namemd  GCC.

-- Gaby

Re: Putting C++ code into gcc front end

[Zack Weinberg]

dewar@gnat.com (Robert Dewar) writes:

> Seriously, I think it is reasonable at this stage to admit C++ more
> widely. Yes, it may complicate build processes a bit, but gcc is a
> huge complex program, and anything that can make it easier to manage
> such a large program by improving abstraction seems a clear win to me.

C++ compilers and runtime libraries that implement the full language
as it was standardized are still rare.  Compilers that implement a
language called "C++" that is incompatible with standard C++ are still
common.

Therefore I think it is premature to consider use of C++ in the
language-independent parts of the compiler, or the C or C++ front
ends.  We should only use C++ in places where it does not force
the user to have a sufficiently new C++ compiler to begin with.

> That being said, I think that, just as GNAT uses a very simple
> straightforward subset of Ada, that is easily read even by those who
> are not Ada experts, it makes sense to approach the use of C++ with
> the same economy of style, and avoid getting too clever with
> language features.

Agree 100% with this point.

zw

Re: Putting C++ code into gcc front end

[Robert Dewar]

> > I think we should abandon the idea that C++ is a second zone class
> > language and just use it as a primary language, which means we should
> > use it where it simplifies programming and where it provides better
> > abstraction tools than plain C.  I support your initiative.
> 
> This can't be worse than using Ada!  [ ducking ]

seems reasonable to me :-)

Seriously, I think it is reasonable at this stage to admit C++ more widely. Yes, it
may complicate build processes a bit, but gcc is a huge complex program, and anything
that can make it easier to manage such a large program by improving abstraction seems
a clear win to me. That being said, I think that, just as GNAT uses a very simple
straightforward subset of Ada, that is easily read even by those who are not Ada
experts, it makes sense to approach the use of C++ with the same economy of style,
and avoid getting too clever with language features.

Re: Putting C++ code into gcc front end

[Mark Mitchell]

--On Tuesday, March 04, 2003 01:13:39 PM +0100 Gabriel Dos Reis 
<gdr@integrable-solutions.net> wrote:

> Richard Earnshaw <rearnsha@arm.com> writes:
>
> | More interesting question is:
> |
> | Could the C++ front end be modified to make it compilable with any C
> | compiler (ignoring for the moment that parts of the C++ front end are
> now  | written in ISO c90).  That is, how many gnu extensions are used,
> and can  | they be easily removed?
>
> I have no idea of how many GNU extensions there are.  Your question is
> probably one of the most important ones to answer.

There are not very many GNU extensions.  I actually know of only one: use
of conditional-expressions as lvalues in a couple of macros.  This could be 
fixed pretty easily.

The C++ front end does expect to get compiled with an ISO c89 compiler 
these days.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Putting C++ code into gcc front end

[Gareth Pearce]

----- Original Message -----
From: "Michael S. Zick" <mszick@goquest.com>
To: "Gareth Pearce" <tilps@hotmail.com>
Cc: <gcc@gcc.gnu.org>
Sent: Wednesday, March 05, 2003 12:42 PM
Subject: Re: Putting C++ code into gcc front end


> On Tuesday 04 March 2003 04:55 pm, Gareth Pearce wrote:
> > Is a random nobody I think i'll contribute how I think compiling gcc
should
> > work.
> >
> > basic pattern
> > stage 0 - compiles a C compiler capable of compiling the C
frontend/backend
> > using minimalistic assumptions about input.
> > stage 1 - compile a C compiler assuming a reasonable standard - such
> > something like as ISO C90
> > stage 2 - compile a C compiler assuming gcc compatible parameters/flags
> > stage 2a - compile things which use C using stage 2- same standard (or
gnu
> > extensions?)
> > stage 2b - compile things dependent on 2a - using stage 2a
> > ... - compile those dependent on previous stage - using previous stage
> > stage 3 - as stage 2
> > stage 3a - see 2a but using stage 3 compiler
> > ...
> > stage 4 - compare stage 2 and stage 3
> > stage 5 - compare 2a 3a - 2b 3b ...
> > stage 6 - run testsuite on either stage 2, 2a... or 3, 3a... (latest one
> > available by default)
> >
> Question...
> If such a plan is adopted, can you make access available on your
> cluster of x390 servers to run the builds?
> Mike
>
and i'll just counter note that unless you run make bootstrap-check - this
system is less compile time then currently. (yes bootstrap-check would be
slow! but it would be less time then running make bootstrap - and i suspect
less time then running make check)

But hey, I said I was dreaming - so sure my ficticious x390 cluster is all
yours.

Gareth

Re: Putting C++ code into gcc front end

[Michael S. Zick]

On Tuesday 04 March 2003 04:55 pm, Gareth Pearce wrote:
> Is a random nobody I think i'll contribute how I think compiling gcc should
> work.
>
> basic pattern
> stage 0 - compiles a C compiler capable of compiling the C frontend/backend
> using minimalistic assumptions about input.
> stage 1 - compile a C compiler assuming a reasonable standard - such
> something like as ISO C90
> stage 2 - compile a C compiler assuming gcc compatible parameters/flags
> stage 2a - compile things which use C using stage 2- same standard (or gnu
> extensions?)
> stage 2b - compile things dependent on 2a - using stage 2a
> ... - compile those dependent on previous stage - using previous stage
> stage 3 - as stage 2
> stage 3a - see 2a but using stage 3 compiler
> ...
> stage 4 - compare stage 2 and stage 3
> stage 5 - compare 2a 3a - 2b 3b ...
> stage 6 - run testsuite on either stage 2, 2a... or 3, 3a... (latest one
> available by default)
>
Question...
If such a plan is adopted, can you make access available on your
cluster of x390 servers to run the builds?
Mike

Re: Putting C++ code into gcc front end

[Mike Stump]

On Monday, March 3, 2003, at 09:41 PM, Gabriel Dos Reis wrote:
> Tom Tromey <tromey@redhat.com> writes:
>
> [...]
>
> | 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 think we should abandon the idea that C++ is a second zone class
> language and just use it as a primary language, which means we should
> use it where it simplifies programming and where it provides better
> abstraction tools than plain C.  I support your initiative.

This can't be worse than using Ada!  [ ducking ]

Re: Putting C++ code into gcc front end

[Diego Novillo]

On Tue, 2003-03-04 at 17:01, Geoff Keating wrote:

> Mind, I wouldn't claim it's a very _useful_ test.  I don't remember
> ever seeing a bootstrap miscomparison that only showed up in the C++
> frontend.
> 
/me raises hand.  Got some of these a while back before we got CCP
working on tree-ssa.  Not anymore, though.


Diego.

Re: Putting C++ code into gcc front end

[Gareth Pearce]

Is a random nobody I think i'll contribute how I think compiling gcc should
work.

basic pattern
stage 0 - compiles a C compiler capable of compiling the C frontend/backend
using minimalistic assumptions about input.
stage 1 - compile a C compiler assuming a reasonable standard - such
something like as ISO C90
stage 2 - compile a C compiler assuming gcc compatible parameters/flags
stage 2a - compile things which use C using stage 2- same standard (or gnu
extensions?)
stage 2b - compile things dependent on 2a - using stage 2a
... - compile those dependent on previous stage - using previous stage
stage 3 - as stage 2
stage 3a - see 2a but using stage 3 compiler
...
stage 4 - compare stage 2 and stage 3
stage 5 - compare 2a 3a - 2b 3b ...
stage 6 - run testsuite on either stage 2, 2a... or 3, 3a... (latest one
available by default)

make
- runs stage 3, 3a... assuming system compiler as input to stage 3

make check
- runs stage 6

make antique
- runs stage 0 - using system compiler

make quickstrap
- runs stage 1 using system compiler
- then stage 3, 3a... using stage 1

make bootstrap
- runs stage 1 using system
- stage 2 using stage 1
- stage 3 using stage 2
- stage 4
- stage 3a, b ...

make bootstrap-check - depends on make bootstrap
- stage 2a, b ... (maybe make b onwards optional here)
- stage 5

okay i'm done, i'll go back to my dream world now...

Gareth

Re: Putting C++ code into gcc front end

[Michael Matz]

Hi,

On Tue, 4 Mar 2003, Geoff Keating wrote:

> Mind, I wouldn't claim it's a very _useful_ test.  I don't remember
> ever seeing a bootstrap miscomparison that only showed up in the C++
> frontend.

I do.  cp/decl.o IIRC, or at least one of the top-three files (regarding
file and object size) in cp/ ;-)


Ciao,
Michael.

Re: Putting C++ code into gcc front end

[Geoff Keating]

> Cc: Phil Edwards <phil@jaj.com>, Richard.Earnshaw@arm.com,
>    Olivier Galibert <galibert@pobox.com>, Rupert Wood <me@rupey.net>,
>    gcc@gcc.gnu.org
> From: Gabriel Dos Reis <gdr@integrable-solutions.net>
> Organization: Integrable Solutions
> Date: 04 Mar 2003 21:54:38 +0100
> X-OriginalArrivalTime: 04 Mar 2003 20:57:15.0666 (UTC) FILETIME=[A2F0E720:01C2E290]
> 
> Geoff Keating <geoffk@geoffk.org> writes:
> 
> | Phil Edwards <phil@jaj.com> writes:
> | 
> | > On Tue, Mar 04, 2003 at 09:29:04AM -0800, Zack Weinberg wrote:
> | > > Ignoring Ada for the moment, what if we only built the C front end,
> | > > optimizers, and back end during all three stages of a bootstrap?  And
> | > > then came back to build the other front ends when we were done?
> | > 
> | > I've always been confused why the C++ frontend was rebuilt multiple times
> | > during a bootstrap; actually assumed that it was done for some kind of odd
> | > binutils compatability or hysterical raisins.  Please, if this is possible,
> | > let's do it.  Bootstrap times will go down as a nice side-effect.
> | 
> | It's a test of the C compiler.  It verifies that the un-optimised C
> | compiler generates the same code as the optimised C compiler.
> 
> Such a test is done when bootstrapping the C compiler proper.

This is a different test, because it tests different source code
inputs.

Mind, I wouldn't claim it's a very _useful_ test.  I don't remember
ever seeing a bootstrap miscomparison that only showed up in the C++
frontend.

> The point is: multiple builds of the C++ front-end is a waste of time
> when your interest is in C++ ;-)

Yes.  This test doesn't test the C++ compiler at all.  If you only
care about C++, you don't need to bootstrap.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Benjamin Kosnik <bkoz@redhat.com> writes:

| > what if we only built the C front end, optimizers, and back end during
| > all three stages of a bootstrap?  And then came back to build the other
| > front ends when we were done?
| 
| I think this sounds like a really good idea.

Seconded.

-- Gaby

Re: Putting C++ code into gcc front end

[Michael Matz]

Hi,

On Tue, 4 Mar 2003, Benjamin Kosnik wrote:

> > what if we only built the C front end, optimizers, and back end during
> > all three stages of a bootstrap?  And then came back to build the other
> > front ends when we were done?
>
> I think this sounds like a really good idea.

No, it's not.  Of course it depends on which parts you're interested.
But for me, bootstrapping more source is better than fewer for reasons
given in another mail from me.  Building the compilers actually doesn't
take that much more time.  Surely less time than libstdc++ and libjava.


Ciao,
Michael.

Re: Putting C++ code into gcc front end

[Michael Matz]

Hi,

On Tue, 4 Mar 2003, Zack Weinberg wrote:

> Ignoring Ada for the moment, what if we only built the C front end,
> optimizers, and back end during all three stages of a bootstrap?  And
> then came back to build the other front ends when we were done?

Possible.  But one needs to be aware, that this removes testcases.  Namely
all non-C compilers.  The testcase being, that stage1 and stage2 cc
compile them the same.  I _did_ hit compare difference in only cp/* in the
past.  If non-C wouldn't have been included, I hadn't, and instead had a
silent miscompilation elsewhere.  I.e. that non-C currently is compared
did help me.


Ciao,
Michael.

Re: Putting C++ code into gcc front end

[Michael Matz]

Hi,

On Tue, 4 Mar 2003, Zack Weinberg wrote:

> > How practical would it be to have '-ansi -pedantic' supplied at stage2?
> > Could we do it on a per front end basis? I suspect all but one of cp's
> > gnuisms is by accident.
>
> In principle you can just change the line setting "cp-warn" in
> cp/Make-lang.in to apply whichever options you want: probably
> -pedantic -Wno-long-long.  (-ansi is a bad idea, it causes system
> headers to change their definition set.)

I am strictly against compiling stage2 with different flags than stage3.
(substitute stage2 and stage3 with the last two to-be-compared stages in
case we go to n-stage boostrap).  Even if those flags should not make the
code different, they might.


Ciao,
Michael.

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Geoff Keating <geoffk@geoffk.org> writes:

| Phil Edwards <phil@jaj.com> writes:
| 
| > On Tue, Mar 04, 2003 at 09:29:04AM -0800, Zack Weinberg wrote:
| > > Ignoring Ada for the moment, what if we only built the C front end,
| > > optimizers, and back end during all three stages of a bootstrap?  And
| > > then came back to build the other front ends when we were done?
| > 
| > I've always been confused why the C++ frontend was rebuilt multiple times
| > during a bootstrap; actually assumed that it was done for some kind of odd
| > binutils compatability or hysterical raisins.  Please, if this is possible,
| > let's do it.  Bootstrap times will go down as a nice side-effect.
| 
| It's a test of the C compiler.  It verifies that the un-optimised C
| compiler generates the same code as the optimised C compiler.

Such a test is done when bootstrapping the C compiler proper.

The point is: multiple builds of the C++ front-end is a waste of time
when your interest is in C++ ;-)

-- Gaby

Re: Putting C++ code into gcc front end

[Geoff Keating]

Phil Edwards <phil@jaj.com> writes:

> On Tue, Mar 04, 2003 at 09:29:04AM -0800, Zack Weinberg wrote:
> > Ignoring Ada for the moment, what if we only built the C front end,
> > optimizers, and back end during all three stages of a bootstrap?  And
> > then came back to build the other front ends when we were done?
> 
> I've always been confused why the C++ frontend was rebuilt multiple times
> during a bootstrap; actually assumed that it was done for some kind of odd
> binutils compatability or hysterical raisins.  Please, if this is possible,
> let's do it.  Bootstrap times will go down as a nice side-effect.

It's a test of the C compiler.  It verifies that the un-optimised C
compiler generates the same code as the optimised C compiler.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Putting C++ code into gcc front end

[Gareth Pearce]

> A good idea for now.   On the other hand...  Bootstraps are a nice
> sanity
> test.  If the C++ front end is ever written in C++, surely we'll want
> to make
> sure it can compile itself.

if this ever happened - it would obviously move back into the bootstrap
process - like ada.

Gareth

Re: Putting C++ code into gcc front end

[Matt Austern]

On Tuesday, March 4, 2003, at 09:40 AM, Benjamin Kosnik wrote:

>
>> The last time this came up, I recall the conclusion being 'not for 3.3
>> but let's revisit this in the 3.4 cycle' which is now.  Personally I'd
>> be happy to see ISO C required for the entire compiler collection at
>> this point.
>
> Seconded. Thirded. I'm running out of hands here....
>
>> what if we only built the C front end, optimizers, and back end during
>> all three stages of a bootstrap?  And then came back to build the 
>> other
>> front ends when we were done?
>
> I think this sounds like a really good idea.

A good idea for now.   On the other hand...  Bootstraps are a nice 
sanity
test.  If the C++ front end is ever written in C++, surely we'll want 
to make
sure it can compile itself.

			--Matt

Re: Putting C++ code into gcc front end

[Zack Weinberg]

Geert Bosch <bosch@gnat.com> writes:

> On Tuesday, Mar 4, 2003, at 13:14 America/New_York, Zack Weinberg wrote:
>
>> make all-libiberty
>> cd gcc
>> make bootstrap LANGUAGES=c  # or "c ada"
>> make LANGUAGES="complete list" CC="./xgcc -B./" CFLAGS="$(BOOT_CFLAGS)"
>> cd ..
>> make all
>
> Unfortunately though, the "make bootstrap LANGUAGES=..." feature
> was removed not too long ago.

That was just for illustration; it can't be done from the command line
but the Makefile is quite capable of it.

zw

Re: Putting C++ code into gcc front end

[Richard Earnshaw]

> 
> On Tuesday, March 4, 2003, at 04:45  AM, Nathan Sidwell wrote:
> > Richard Earnshaw wrote:
> >
> >> Could the C++ front end be modified to make it compilable with any C 
> >> compiler (ignoring for the moment that parts of the C++ front end are 
> >> now written in ISO c90).  That is, how many gnu extensions are used, 
> >> and can they be easily removed?
> > a quick compile with -pedantic shows,
> > char bitfields such as
> > 1 cp-tree.h: unsigned char is_lang_type_class : 1;. Making this an int 
> > would
> >   enlarge that structure.
> > 2 the tree checking stuff uses '({ ...})', but only when compiled with 
> > GCC
> > 3 decl.c: (cond_expr) = value
> >   this hides inside things like 'current_binding_level = newlevel;'
> > 4 some minor syntactic things that have crept in (extra ',', ';')
> 
> If you really want to be compliant, all external names have to be unique
> within 6 characters, case-insensitive (3.1.2).  Somehow I doubt that's 
> going to happen.
> 
Here's something frightening:

nm -Pg cc1|awk '{ print $1 }'|sort|sed -e 's/^\(......\).*$/\1/'>/tmp/out
uniq /tmp/out > /tmp/out2
wc -l /tmp/out*
   3771 /tmp/out
   1449 /tmp/out2


ie more than 1/2 of global symbols in the cc1 compiler are not unique in 
the first 6 characters.

R.

Re: Putting C++ code into gcc front end

[Daniel Berlin]

On Tuesday, March 4, 2003, at 12:36  PM, Phil Edwards wrote:

> On Tue, Mar 04, 2003 at 06:06:29PM +0100, Steven Bosscher wrote:
>> Op di 04-03-2003, om 15:45 schreef Richard Earnshaw:
>>>> Is it reasonable in 2003 to have a quite complex compiler written in
>>>> K&R C?  Not even ISO C?
>>>
>>> The last time this came up (probably less than 6 months ago), the 
>>> answer
>>> was "yes".  We've been round this discussion before.  Let's not 
>>> rehash all
>>> the same old arguments again.
>>
>> I believe that the answer was: "Yes, because we have exactly one
>> platform that does not come with an ISO C compiler (HPUX).  We will 
>> look
>> at this issue again in the 3.4 time frame".
>
> Daniel Berlin wrote what is IMHO the best and most precise summary of 
> all
> arguments for removing the K&R requirement:
>
>     http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00675.html
>
> Note the "HP agrees with us" bit.

and in case people are curious where i drew that conclusion from, i 
noticed that i forgot to mention sources.
Just so one doesn't think i'm making it up, it's repeated by HP people 
at every turn. For example:
http://h21007.www2.hp.com/hpux-devtools/CXX/hpux-devtools.0203/0017.html
(Note: "Not suitable for application development")
In fact,  "The bundled C compiler, strictly speaking, shouldn't be 
referred to as a
K&R compiler either.  It's really just been given enough features to be
able to compile the kernel." (from an email i don't have a URL because 
it was forwarded to me by an HP person).

That made me laugh a bit, then cry.
--Dan

Re: Putting C++ code into gcc front end

[Geert Bosch]

On Tuesday, Mar 4, 2003, at 13:14 America/New_York, Zack Weinberg wrote:

> make all-libiberty
> cd gcc
> make bootstrap LANGUAGES=c  # or "c ada"
> make LANGUAGES="complete list" CC="./xgcc -B./" CFLAGS="$(BOOT_CFLAGS)"
> cd ..
> make all

Unfortunately though, the "make bootstrap LANGUAGES=..." feature
was removed not too long ago.

   -Geert

Re: Putting C++ code into gcc front end

[Geert Bosch]

On Tuesday, Mar 4, 2003, at 12:29 America/New_York, Zack Weinberg wrote:

> Ignoring Ada for the moment, what if we only built the C front end,
> optimizers, and back end during all three stages of a bootstrap?  And 
> then came back to build the other front ends when we were
> done?  At that point, using C++ in the Java front end becomes
> substantially less hassle: we just have to make sure the C++
> front end and runtime library are built first.  This effectively
> puts each front end on the same footing as its runtime library.

I think this is a really good idea, I don't really see any
strong arguments for building the C++ compiler twice. The
argument against is that we're wasting everybody's time and
needlessly complicate build procedures and restrict ourselves
to whatever system compiler happens to be around instead of
using our own product.

   -Geert

Re: Putting C++ code into gcc front end

[Zack Weinberg]

Nathanael Nerode <neroden@twcny.rr.com> writes:

>>Ignoring Ada for the moment, what if we only built the C front end,
>>optimizers, and back end during all three stages of a bootstrap?  And
>>then came back to build the other front ends when we were done?  At
>>that point, using C++ in the Java front end becomes substantially less
>>hassle: we just have to make sure the C++ front end and runtime
>>library are built first.  This effectively puts each front end on the
>>same footing as its runtime library.
>
> Uh.  The problem is, simply, that currently all languages are built as 
> part of 'one compiler'.  I'm not sure it's safe or easy to try to 
> decouple the middle-end/back-end build from the front end builds as much 
> as you (and Gaby) seem to be suggesting.  It may be, I'm just not sure.

I think it is easy - configure all languages, then do the equivalent
of

make all-libiberty
cd gcc
make bootstrap LANGUAGES=c  # or "c ada"
make LANGUAGES="complete list" CC="./xgcc -B./" CFLAGS="$(BOOT_CFLAGS)"
cd ..
make all

> If it isn't easy, then 'making sure the C++ front end and runtime 
> library are built first' means 'making sure a complete build is 
> done including C++ first', which means *extra stages*.  This is the 
> point I seem to have trouble getting across.

Oh, I'm quite aware for the need for extra stages if we don't do
something like the above.

zw

Re: Putting C++ code into gcc front end

[Dale Johannesen]

On Tuesday, March 4, 2003, at 04:45  AM, Nathan Sidwell wrote:
> Richard Earnshaw wrote:
>
>> Could the C++ front end be modified to make it compilable with any C 
>> compiler (ignoring for the moment that parts of the C++ front end are 
>> now written in ISO c90).  That is, how many gnu extensions are used, 
>> and can they be easily removed?
> a quick compile with -pedantic shows,
> char bitfields such as
> 1 cp-tree.h: unsigned char is_lang_type_class : 1;. Making this an int 
> would
>   enlarge that structure.
> 2 the tree checking stuff uses '({ ...})', but only when compiled with 
> GCC
> 3 decl.c: (cond_expr) = value
>   this hides inside things like 'current_binding_level = newlevel;'
> 4 some minor syntactic things that have crept in (extra ',', ';')

If you really want to be compliant, all external names have to be unique
within 6 characters, case-insensitive (3.1.2).  Somehow I doubt that's 
going to happen.

Re: Putting C++ code into gcc front end

[Nathanael Nerode]

Zack sez:
>Couple that with Gabriel's point that building all the other front
>ends during the bootstrap doesn't really do anything useful...
It tests the GCC C compiler on the code in the other front ends.  This 
is, technically, something useful. :-)

>Ignoring Ada for the moment, what if we only built the C front end,
>optimizers, and back end during all three stages of a bootstrap?  And
>then came back to build the other front ends when we were done?  At
>that point, using C++ in the Java front end becomes substantially less
>hassle: we just have to make sure the C++ front end and runtime
>library are built first.  This effectively puts each front end on the
>same footing as its runtime library.

Uh.  The problem is, simply, that currently all languages are built as 
part of 'one compiler'.  I'm not sure it's safe or easy to try to 
decouple the middle-end/back-end build from the front end builds as much 
as you (and Gaby) seem to be suggesting.  It may be, I'm just not sure.
If it isn't easy, then 'making sure the C++ front end and runtime 
library are built first' means 'making sure a complete build is 
done including C++ first', which means *extra stages*.  This is the 
point I seem to have trouble getting across.

Let me try to say it another way.  Can we -- easily -- build a 'C only' 
compiler and then 'add' C++ to that compiler?  I'm guessing no, in which 
case the only easy things to do are to build a 'C only' compiler and 
then build a 'C and C++' compiler (extra stage), or just build a 'C and 
C++' compiler to start with (requires C90 system compiler and C90 
compliance in the C++ front end -- or K&R compliance in the C++ front 
end).

--Nathanael

Re: Putting C++ code into gcc front end

[Benjamin Kosnik]

> The last time this came up, I recall the conclusion being 'not for 3.3
> but let's revisit this in the 3.4 cycle' which is now.  Personally I'd
> be happy to see ISO C required for the entire compiler collection at
> this point.

Seconded. Thirded. I'm running out of hands here....

> what if we only built the C front end, optimizers, and back end during
> all three stages of a bootstrap?  And then came back to build the other
> front ends when we were done?

I think this sounds like a really good idea.

-benjamin

Re: Putting C++ code into gcc front end

[Phil Edwards]

On Tue, Mar 04, 2003 at 09:29:04AM -0800, Zack Weinberg wrote:
> Ignoring Ada for the moment, what if we only built the C front end,
> optimizers, and back end during all three stages of a bootstrap?  And
> then came back to build the other front ends when we were done?

I've always been confused why the C++ frontend was rebuilt multiple times
during a bootstrap; actually assumed that it was done for some kind of odd
binutils compatability or hysterical raisins.  Please, if this is possible,
let's do it.  Bootstrap times will go down as a nice side-effect.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Putting C++ code into gcc front end

[Phil Edwards]

On Tue, Mar 04, 2003 at 06:06:29PM +0100, Steven Bosscher wrote:
> Op di 04-03-2003, om 15:45 schreef Richard Earnshaw:
> > > Is it reasonable in 2003 to have a quite complex compiler written in
> > > K&R C?  Not even ISO C?
> > 
> > The last time this came up (probably less than 6 months ago), the answer 
> > was "yes".  We've been round this discussion before.  Let's not rehash all 
> > the same old arguments again.
> 
> I believe that the answer was: "Yes, because we have exactly one
> platform that does not come with an ISO C compiler (HPUX).  We will look
> at this issue again in the 3.4 time frame".

Daniel Berlin wrote what is IMHO the best and most precise summary of all
arguments for removing the K&R requirement:

    http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00675.html

Note the "HP agrees with us" bit.

For my own part, the changes in my local trees are all in ISO C, and
-Wno-traditional added where needed as a result.  I have no intention
of ever writing K&R C again.  The language has been standardized for a
freaking decade; I refuse to hobble myself because some HPUX user wants
to bootstrap with a "for kernel rebuilding only" compiler.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Putting C++ code into gcc front end

[Tom Tromey]

>>>>> "Lars" == Lars Segerlund <lars.segerlund@comsys.se> writes:

Lars> I still think this spels out the solution, rewrite the libgcj
Lars> checker in C, wrap in C++ use in libgcj, and the c part in the
Lars> frontend.

If it comes to this, it may be cheaper to just try to fix the bugs in
the gcj verifier and maintain the two versions in parallel.

For instance, the libgcj verifier assumes it can throw an exception
from just about anywhere to indicate a failure.  Porting this to C
would mean a major revamp of all the control throw (or the use of
longjmp, I suppose).

Tom

Re: Putting C++ code into gcc front end

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> | > And bootstrap for C++ front-end is currently an oxymoron: it is just a
> | > bootstrap for the C compiler.
> | 
> | I consider this a feature.
>
> Clearly, we do not have the same definition of feature.
>
> I consider a definition of "boostrapping the C++ compiler" which just
> means "bootstrapping the C compiler" a bug.

Terminological confusion.  I consider it a feature that bootstrapping
GCC (the entire collection) exercises only the C (and Ada) compilers;
in other words I think it is desirable _not_ to bootstrap the C++
front end.

zw

Re: Putting C++ code into gcc front end

[Zack Weinberg]

Richard Earnshaw <rearnsha@arm.com> writes:

>> Is it reasonable in 2003 to have a quite complex compiler written in
>> K&R C?  Not even ISO C?
>
> The last time this came up (probably less than 6 months ago), the answer 
> was "yes".  We've been round this discussion before.  Let's not rehash all 
> the same old arguments again.

The last time this came up, I recall the conclusion being 'not for 3.3
but let's revisit this in the 3.4 cycle' which is now.  Personally I'd
be happy to see ISO C required for the entire compiler collection at
this point.

> personally, I'd be happy to see people using K+R only compilers to
> start the bootstrap having to do a 4th stage (so that only the C
> compiler has to be K+R).  It might even mean that the stage0
> compiler only contains enough code to do non-optimizing
> compilations.

Couple that with Gabriel's point that building all the other front
ends during the bootstrap doesn't really do anything useful...

Ignoring Ada for the moment, what if we only built the C front end,
optimizers, and back end during all three stages of a bootstrap?  And
then came back to build the other front ends when we were done?  At
that point, using C++ in the Java front end becomes substantially less
hassle: we just have to make sure the C++ front end and runtime
library are built first.  This effectively puts each front end on the
same footing as its runtime library.

I also like your idea of a stage0 compiler that only contains enough
code to do non-optimizing compilation.  That means we do not have to
worry about the bootstrap compiler generating incorrect code for the
optimizers.  (Unfortunately I doubt this helps much -- the hairiest
code in GCC is stuff that would still be required.)

zw

Re: Putting C++ code into gcc front end

[Benjamin Kosnik]

> The bottom line was: We should be able to use C++ where appropriate.

Too bad "be able" isn't the same as "free" here.

Even more to Tom's original point: it's a waste of valuable maintainer
time to re-write C++ bits in C. We are all too busy as it is: "C"
translation busy work is not helpful. It's not easy to do, some ideas
and code organization methods are hard or impossible to express in C,
the end result is sometimes a disappointment, and the situation then
becomes even more difficult to maintain with two separate versions in
two languages.

I think Richard Earnshaw has indicated the way forward here. Instead of
penalizing every gcc user with a modern compiler (the vast majority),
instead make the K&R folk do a pre-bootstrap stage-0 compiler. This
seems sane.

Next, the C++ front end converted to ISO C. Kaveh, Richard Earnshaw, and
Nathan seem to agree that this is possible.

Then, everything is cool.

-benjamin

Re: Putting C++ code into gcc front end

[Andrew Haley]

Lars Segerlund writes:
 > 
 >   This reply I don't understand, there is a note on gcc and why it's 
 > written in C in the docs, also refering to meningless religious debates, 
 > if we haven't got a reason to have C++ in the fronend why should we ? 

We do have a reason.  See
http://gcc.gnu.org/ml/gcc/2003-03/msg00146.html.

 > also since it has the potential to be seriously misused and make compile 
 > times skyrocket.

But we don't have to accept inefficient patches.  Inefficiency is a
feature of a patch, not whether it was written in C or C++.

 > This last statement clearly states misused ! In the 
 > same manner as the garbage collector has been misused and caused C++ 
 > compile times to skyrocket, it does in no way imply that C++ is broken 
 > or anything.
 > 
 >   If I understand the bottom line it is that we 'should' have C++ in the 
 > frontends ?

Well, yes.  Otherwise we won't be able to use code that is already
written in C++ in our front ends.

 >   Also in regards to thrust, I do not se how this reflect's on not 
 > having C++ in the frontends ? I view the issue as having a minimal set 
 > of prerequitites for the frontend, there is no java, fortran, ada and 
 > such in the frontend. ( for ada I believe this to be wrong but I am not 
 > sure ).

 >   Also I do believe that the C++ libs and java libs are the only libs 
 > with C++ in them, in strict contrast to all other major languages 
 > supported by the compiler such as fortran, cobol, ada.
 > 
 >   Is there a rational reason to have a rewrite of gcc instead of a minor 
 > rewrite of a lib for a target language ?

We're not rewriting anything.  In fact, we're trying to avoid rewriting
part of the front end for Java.

Andrew.

Re: Putting C++ code into gcc front end

[Zack Weinberg]

Nathan Sidwell <nathan@codesourcery.com> writes:

> Kaveh R. Ghazi wrote:
>>  > The C++ frontend is written in K&R C with gcc extensions (talk about perverted).
>> The C++ frontend is (very slowly) being coverted to ISO C on the
>> mainline sources for 3.4.
> How practical would it be to have '-ansi -pedantic' supplied at stage2?
> Could we do it on a per front end basis? I suspect all but one of cp's
> gnuisms is by accident.

In principle you can just change the line setting "cp-warn" in
cp/Make-lang.in to apply whichever options you want: probably
-pedantic -Wno-long-long.  (-ansi is a bad idea, it causes system
headers to change their definition set.)

It is trickier than that if you want the right thing done in stage 1,
because we need to suppress -Wno-long-long for old bootstrap compilers
that don't understand it.  See what is currently done for
STRICT_WARN/STRICT2_WARN.

zw

Re: Putting C++ code into gcc front end

[Steven Bosscher]

Op di 04-03-2003, om 15:45 schreef Richard Earnshaw:
> > Is it reasonable in 2003 to have a quite complex compiler written in
> > K&R C?  Not even ISO C?
> 
> The last time this came up (probably less than 6 months ago), the answer 
> was "yes".  We've been round this discussion before.  Let's not rehash all 
> the same old arguments again.

I believe that the answer was: "Yes, because we have exactly one
platform that does not come with an ISO C compiler (HPUX).  We will look
at this issue again in the 3.4 time frame".

Greetz
Steven

Re: Putting C++ code into gcc front end

[Nathanael Nerode]

Richard Earnshaw said:

>personally, I'd be happy to see people using K+R only compilers to 
>start 
>the bootstrap having to do a 4th stage (so that only the C compiler has 
>to 
>be K+R).  It might even mean that the stage0 compiler only contains 
>enough 
>code to do non-optimizing compilations.

I think that sounds fine too.  If we accepted that, *and* we made the 
C++ front end C89 compliant, then we could put C++ code into the Java 
front end without having to add a 4th stage to bootstrap (for people 
with an ISO system compiler).

The fact that the C++ front end uses GNU extensions currently is the 
only reason I disapprove of putting C++ into the Java front end.  With 
the GNU extensions, it means a 3-stage bootstrap would be impossible 
with a non-GCC system compiler.  (People with only K&R system 
compilers... well, I don't care that much.)

--Nathanael

Re: Putting C++ code into gcc front end

[Nathan Sidwell]

Kaveh R. Ghazi wrote:
>  > The C++ frontend is written in K&R C with gcc extensions (talk about perverted).
> 
> The C++ frontend is (very slowly) being coverted to ISO C on the
> mainline sources for 3.4.
How practical would it be to have '-ansi -pedantic' supplied at stage2?
Could we do it on a per front end basis? I suspect all but one of cp's
gnuisms is by accident.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Putting C++ code into gcc front end

[Nathan Sidwell]

Richard Earnshaw wrote:
>>Richard Earnshaw wrote:
>>
>>
>>>Could the C++ front end be modified to make it compilable with any C 
>>>compiler (ignoring for the moment that parts of the C++ front end are now 
>>>written in ISO c90).  That is, how many gnu extensions are used, and can 
>>>they be easily removed?
>>
>>a quick compile with -pedantic shows,
>>char bitfields such as
>>1 cp-tree.h: unsigned char is_lang_type_class : 1;. Making this an int would
>>   enlarge that structure.
> 
> 
> The comment preceding lang_type_header already indicates that some of the 
> bits there logically belong in lang_type_class.  And a quick look through 
> the header suggests that only one use really relies on this being an 
> eight-bit field and that is lang_type_class: the other two uses are 1) a 
> Union 2) lang_type_ptrmem (where it is already followed by a 32-bit 
> aligned object.
> 
> So if we made this a bitfield of an int, we could push up to 32-bits worth 
> of things into lang_type_header and the cost would be zero.
sounds ok to me. I'd encourange making cp conform to C89, rather than GNU89.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Putting C++ code into gcc front end

[Kaveh R. Ghazi]

 > I'm expectiting that we'll revisit the ISO C90 requirements for 3.5,
 > and that revision will be positive.

I'm a little disappointed that it's taking so long to finish
converting the C++ frontend.

Having things in a halfway state is messy and makes the code harder to
read and maintain.  So I wouldn't vote to open up new parts of the
compiler for conversion until the existing opened parts were
completed.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Putting C++ code into gcc front end

[Kaveh R. Ghazi]

Your information is slightly out of date:


 > The fortran library is written in atrociously mixed K&R/ISO C.

I converted libf2c to ISO C as of gcc-3.3.


 > The C++ frontend is written in K&R C with gcc extensions (talk about perverted).

The C++ frontend is (very slowly) being coverted to ISO C on the
mainline sources for 3.4.


 > The java frontend is written in K&R C with maybe C++ in the future.
 >   OG.

I converted the java frontend to ISO C in the mainline sources for 3.4.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Putting C++ code into gcc front end

[Olivier Galibert]

On Tue, Mar 04, 2003 at 04:19:56PM +0100, Lars Segerlund wrote:
>   If I understand the bottom line it is that we 'should' have C++ in the 
> frontends ?

My personal POV is that at least we should have a modern C, not K&R
unreadable crap.  C++ would probably help even more for the kind of
complex manipulations that are done f.i. in ssa, but the reluctance
still seems too high.


>   Also in regards to thrust, I do not se how this reflect's on not 
> having C++ in the frontends ? I view the issue as having a minimal set 
> of prerequitites for the frontend, there is no java, fortran, ada and 
> such in the frontend. ( for ada I believe this to be wrong but I am not 
> sure ).
> 
>   Also I do believe that the C++ libs and java libs are the only libs 
> with C++ in them, in strict contrast to all other major languages 
> supported by the compiler such as fortran, cobol, ada.

The ada frontend is written in ada and K&R C.
The ada library is written in ada.
The fortran frontend is written in ISO C.
The fortran library is written in atrociously mixed K&R/ISO C.
The C++ frontend is written in K&R C with gcc extensions (talk about perverted).
The C++ library is written in C++.
The java frontend is written in K&R C with maybe C++ in the future.
The java library is written in C++ and java.

Cobol is not in 3.2.2.

It's not that cut and dried.

  OG.

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Lars Segerlund <lars.segerlund@comsys.se> writes:

|   If I understand the bottom line it is that we 'should' have C++ in
| the frontends ?

You didn't understand the bottom line.

The bottom line was: We should be able to use C++ where appropriate.
We should be not be forced to rewrite C++ codes in K+R just because we
are making difficult to explain requirements wheress the vast
majority of the world have compilers that understand C90.

[...]

|   Is there a rational reason to have a rewrite of gcc instead of a
| minor rewrite of a lib for a target language ?

Was I proposing to rewrite GCC in C++?

(I may but I didn't).

-- Gaby

Re: Putting C++ code into gcc front end

[Lars Segerlund]

  This reply I don't understand, there is a note on gcc and why it's 
written in C in the docs, also refering to meningless religious debates, 
if we haven't got a reason to have C++ in the fronend why should we ? 
also since it has the potential to be seriously misused and make compile 
times skyrocket. This last statement clearly states misused ! In the 
same manner as the garbage collector has been misused and caused C++ 
compile times to skyrocket, it does in no way imply that C++ is broken 
or anything.

  If I understand the bottom line it is that we 'should' have C++ in the 
frontends ?

  Also in regards to thrust, I do not se how this reflect's on not 
having C++ in the frontends ? I view the issue as having a minimal set 
of prerequitites for the frontend, there is no java, fortran, ada and 
such in the frontend. ( for ada I believe this to be wrong but I am not 
sure ).

  Also I do believe that the C++ libs and java libs are the only libs 
with C++ in them, in strict contrast to all other major languages 
supported by the compiler such as fortran, cobol, ada.

  Is there a rational reason to have a rewrite of gcc instead of a minor 
rewrite of a lib for a target language ?

  Now the above is opinions.

  / Lars Segerlund.

Gabriel Dos Reis wrote:
> Lars Segerlund <lars.segerlund@comsys.se> writes:
> 
> |   I still think this spels out the solution, rewrite the libgcj
> | checker in C, wrap in C++ use in libgcj, and the c part in the
> | frontend.
> 
> We cannot indefinitely refuse to bite the bullet and solve the problem
> for once.
> 
> If we cannot trust and use our product, how can we persuade users
> that it worths it? 
> 
> -- Gaby
> 

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Olivier Galibert <galibert@pobox.com> writes:

| On Tue, Mar 04, 2003 at 03:52:57PM +0100, Gabriel Dos Reis wrote:
| > On this issue, in my opinion, we should proceed in steps.  
| > I believe R.'s approach is a fair first step.  Let's make the C++
| > front-end compilable by ISO C90 compilers.  Then we'll tackle the next
| > issue in due time.
| 
| But if the C++ front-end requires ISO C90, then you'll need the 4 (or
| 3, depending on how you count) passes bootstrap for java anyway.

I'm expectiting that we'll revisit the ISO C90 requirements for 3.5,
and that revision will be positive.  Which will make C and C++
front-ends on equal footing.  That will require less stages than
currently feared.

In the meantime, I'm convinced that R.'s proposal is a fair one.
This issue should not be a zero-or-one issue. 

| Either you downgrade the C++ front-end all the way back to K&R or
| there is no need to bother since you'll have to do the first compile
| with the pass1 xgcc anyway.
| 
| You have a limited number of possibilities here:
| - go 4-pass for java
| - downgrade the c++ frontend all the way to the C front-end required
|   level, ie K&R
| - change the c++ frontend back to ISO C _and_ upgrade the requirements
|   to ISO C

I believe it is reasonable to expect that some who wants to build a
C++ ou Java compiler has access to a compiler that supports C90.  I
would like that expectation to apply to C90 compiler as well, but
we've been through this in the past and I do not believe we've new
arguments to convince C folks to raise the requirements. 

-- Gaby

Re: Putting C++ code into gcc front end

[Richard Earnshaw]

> On Tue, Mar 04, 2003 at 03:52:57PM +0100, Gabriel Dos Reis wrote:
> > On this issue, in my opinion, we should proceed in steps.  
> > I believe R.'s approach is a fair first step.  Let's make the C++
> > front-end compilable by ISO C90 compilers.  Then we'll tackle the next
> > issue in due time.
> 
> But if the C++ front-end requires ISO C90, then you'll need the 4 (or
> 3, depending on how you count) passes bootstrap for java anyway.
> Either you downgrade the C++ front-end all the way back to K&R or
> there is no need to bother since you'll have to do the first compile
> with the pass1 xgcc anyway.
> 
> You have a limited number of possibilities here:
> - go 4-pass for java
> - downgrade the c++ frontend all the way to the C front-end required
>   level, ie K&R
> - change the c++ frontend back to ISO C _and_ upgrade the requirements
>   to ISO C
> 
> Moving the C++ frontend to iso C without upgrading the requirements
> won't do.

The vast majority of the world now has ISO C (the main exception is the 
bundled HPUX compiler); this doesn't have to be GCC, just ISO C.  So most 
of the world would be able to build C++ during stage1 of the bootstrap 
(rather than in stages 2 & 3).

For those with only a K+R compiler we wouldn't cut them off entirely, we'd 
just say that you have to build GCC's C compiler first (stage0).

So yes, it is 4-stage, but only if you start out with a K+R compiler.

R.

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Lars Segerlund <lars.segerlund@comsys.se> writes:

|   I still think this spels out the solution, rewrite the libgcj
| checker in C, wrap in C++ use in libgcj, and the c part in the
| frontend.

We cannot indefinitely refuse to bite the bullet and solve the problem
for once.

If we cannot trust and use our product, how can we persuade users
that it worths it? 

-- Gaby

Re: Putting C++ code into gcc front end

[Olivier Galibert]

On Tue, Mar 04, 2003 at 03:52:57PM +0100, Gabriel Dos Reis wrote:
> On this issue, in my opinion, we should proceed in steps.  
> I believe R.'s approach is a fair first step.  Let's make the C++
> front-end compilable by ISO C90 compilers.  Then we'll tackle the next
> issue in due time.

But if the C++ front-end requires ISO C90, then you'll need the 4 (or
3, depending on how you count) passes bootstrap for java anyway.
Either you downgrade the C++ front-end all the way back to K&R or
there is no need to bother since you'll have to do the first compile
with the pass1 xgcc anyway.

You have a limited number of possibilities here:
- go 4-pass for java
- downgrade the c++ frontend all the way to the C front-end required
  level, ie K&R
- change the c++ frontend back to ISO C _and_ upgrade the requirements
  to ISO C

Moving the C++ frontend to iso C without upgrading the requirements
won't do.

  OG.

Re: Putting C++ code into gcc front end

[Lars Segerlund]

  I still think this spels out the solution, rewrite the libgcj checker 
in C, wrap in C++ use in libgcj, and the c part in the frontend.

  Simple.

  / Lars Segerlund.

Michael Matz wrote:
> Hi,
> 
> On 3 Mar 2003, Tom Tromey wrote:
> 
> 
>>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.
>>
>>In case it matters, the C++ code in question is in gcc/libjava/verify.cc.
> 
> 
> Regarding the use of C++ in the non-{C,C++} frontends I'm undecided.  But
> if something like verify.cc gets into bootstrap process, we somewhen need
> to speed up the compiler.  verify.cc and interpret.cc are two of the most
> time suckers in compiling the compiler generally and libjava especially.
> I wouldn't like to have this code compiled three times.
> 
> 
> Ciao,
> Michael.
> 
> 

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

| Hi,
| 
| On 3 Mar 2003, Tom Tromey wrote:
| 
| > 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.
| >
| > In case it matters, the C++ code in question is in gcc/libjava/verify.cc.
| 
| Regarding the use of C++ in the non-{C,C++} frontends I'm undecided.  But
| if something like verify.cc gets into bootstrap process, we somewhen need
| to speed up the compiler.  verify.cc and interpret.cc are two of the most
| time suckers in compiling the compiler generally and libjava especially.
| I wouldn't like to have this code compiled three times.

I believe the compiler compile-time performance is part of release criteria.

-- Gaby

Re: Putting C++ code into gcc front end

[Michael Matz]

Hi,

On 3 Mar 2003, Tom Tromey wrote:

> 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.
>
> In case it matters, the C++ code in question is in gcc/libjava/verify.cc.

Regarding the use of C++ in the non-{C,C++} frontends I'm undecided.  But
if something like verify.cc gets into bootstrap process, we somewhen need
to speed up the compiler.  verify.cc and interpret.cc are two of the most
time suckers in compiling the compiler generally and libjava especially.
I wouldn't like to have this code compiled three times.


Ciao,
Michael.

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

| > > Just at this point it isn't reasonable to assume that there 
| > > are conforming (even sufficiently conforming) C++ compilers widely 
| > > available on the wide range of hosts that GCC currently supports.
| > 
| > There is gcc 3.2.2.
| 
| But that doesn't support hosts that might come along in the future

Right.

On this issue, in my opinion, we should proceed in steps.  
I believe R.'s approach is a fair first step.  Let's make the C++
front-end compilable by ISO C90 compilers.  Then we'll tackle the next
issue in due time.

-- Gaby

Re: Putting C++ code into gcc front end

[Richard Earnshaw]

> > Just at this point it isn't reasonable to assume that there 
> > are conforming (even sufficiently conforming) C++ compilers widely 
> > available on the wide range of hosts that GCC currently supports.
> 
> There is gcc 3.2.2.

But that doesn't support hosts that might come along in the future (or are 
you proposing to maintain it in perpetuity?)

> 
> > Anyway defining a suitable subset of C++ that we could expect is 
> > 1) hard -- we don't know enough about all the c++ compilers out there.
> > 2) impossible to enforce rigorously without modifying the compiler to 
> > allow us to detect extensions from the subset.
> 
> Maybe.  Maybe you only really need to care about being able to compile
> with gcc from 2 or 3 major versions past, as gnat seems to do.
> 
> Is it reasonable in 2003 to have a quite complex compiler written in
> K&R C?  Not even ISO C?

The last time this came up (probably less than 6 months ago), the answer 
was "yes".  We've been round this discussion before.  Let's not rehash all 
the same old arguments again.

personally, I'd be happy to see people using K+R only compilers to start 
the bootstrap having to do a 4th stage (so that only the C compiler has to 
be K+R).  It might even mean that the stage0 compiler only contains enough 
code to do non-optimizing compilations.

But that's my opinion and it may well not be shared by other maintainers.  

R.

Re: Putting C++ code into gcc front end

[Olivier Galibert]

On Tue, Mar 04, 2003 at 02:19:51PM +0000, Richard Earnshaw wrote:
> Fixing the current c++ compiler so that it can be compiled with any ISO C 
> compiler is a completely different level of change from permitting C++ 
> everywhere.

Sure.


> Just at this point it isn't reasonable to assume that there 
> are conforming (even sufficiently conforming) C++ compilers widely 
> available on the wide range of hosts that GCC currently supports.

There is gcc 3.2.2.


> Anyway defining a suitable subset of C++ that we could expect is 
> 1) hard -- we don't know enough about all the c++ compilers out there.
> 2) impossible to enforce rigorously without modifying the compiler to 
> allow us to detect extensions from the subset.

Maybe.  Maybe you only really need to care about being able to compile
with gcc from 2 or 3 major versions past, as gnat seems to do.

Is it reasonable in 2003 to have a quite complex compiler written in
K&R C?  Not even ISO C?

  OG.

Re: Putting C++ code into gcc front end

[Richard Earnshaw]

> On Tue, Mar 04, 2003 at 01:13:39PM +0100, Gabriel Dos Reis wrote:
> > I have no idea of how many GNU extensions there are.  Your question is
> > probably one of the most important ones to answer. 
> 
> Or, the other way around, what about requiring a system C++ compiler
> and start using C++[1] in all the front and back ends where useful ?
> 
>   OG.
> 
> [1] Maybe not all of C++ immediatly, of course.

Fixing the current c++ compiler so that it can be compiled with any ISO C 
compiler is a completely different level of change from permitting C++ 
everywhere.  Just at this point it isn't reasonable to assume that there 
are conforming (even sufficiently conforming) C++ compilers widely 
available on the wide range of hosts that GCC currently supports.

Anyway defining a suitable subset of C++ that we could expect is 
1) hard -- we don't know enough about all the c++ compilers out there.
2) impossible to enforce rigorously without modifying the compiler to 
allow us to detect extensions from the subset.

Re: Putting C++ code into gcc front end

[Richard Earnshaw]

> Richard Earnshaw wrote:
> 
> > Could the C++ front end be modified to make it compilable with any C 
> > compiler (ignoring for the moment that parts of the C++ front end are now 
> > written in ISO c90).  That is, how many gnu extensions are used, and can 
> > they be easily removed?
> a quick compile with -pedantic shows,
> char bitfields such as
> 1 cp-tree.h: unsigned char is_lang_type_class : 1;. Making this an int would
>    enlarge that structure.

The comment preceding lang_type_header already indicates that some of the 
bits there logically belong in lang_type_class.  And a quick look through 
the header suggests that only one use really relies on this being an 
eight-bit field and that is lang_type_class: the other two uses are 1) a 
Union 2) lang_type_ptrmem (where it is already followed by a 32-bit 
aligned object.

So if we made this a bitfield of an int, we could push up to 32-bits worth 
of things into lang_type_header and the cost would be zero.

R.

Re: Putting C++ code into gcc front end

[Lars Segerlund]

  Rewrite the lib in C instead of C++ and the problem is gone, this must 
be much easier.

  / Lars Segerlund.

Olivier Galibert wrote:
> On Tue, Mar 04, 2003 at 01:13:39PM +0100, Gabriel Dos Reis wrote:
> 
>>I have no idea of how many GNU extensions there are.  Your question is
>>probably one of the most important ones to answer. 
> 
> 
> Or, the other way around, what about requiring a system C++ compiler
> and start using C++[1] in all the front and back ends where useful ?
> 
>   OG.
> 
> [1] Maybe not all of C++ immediatly, of course.
> 

Re: Putting C++ code into gcc front end

[Olivier Galibert]

On Tue, Mar 04, 2003 at 01:13:39PM +0100, Gabriel Dos Reis wrote:
> I have no idea of how many GNU extensions there are.  Your question is
> probably one of the most important ones to answer. 

Or, the other way around, what about requiring a system C++ compiler
and start using C++[1] in all the front and back ends where useful ?

  OG.

[1] Maybe not all of C++ immediatly, of course.

Re: Putting C++ code into gcc front end

[Nathan Sidwell]

Richard Earnshaw wrote:

> Could the C++ front end be modified to make it compilable with any C 
> compiler (ignoring for the moment that parts of the C++ front end are now 
> written in ISO c90).  That is, how many gnu extensions are used, and can 
> they be easily removed?
a quick compile with -pedantic shows,
char bitfields such as
1 cp-tree.h: unsigned char is_lang_type_class : 1;. Making this an int would
   enlarge that structure.
2 the tree checking stuff uses '({ ...})', but only when compiled with GCC
3 decl.c: (cond_expr) = value
   this hides inside things like 'current_binding_level = newlevel;'
4 some minor syntactic things that have crept in (extra ',', ';')

There is certainly intent to have it C89 compliant. Perhaps we should fix
those digressions correctly. #2 can be fixed with appropriate
__extension__ keywords. #3 is fixable by something like
	#define current_binding_level (*(cond ? &truething : &falsething)).
#4 is trivial. #1 may be more awkward without expanding the struct.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Richard Earnshaw <rearnsha@arm.com> writes:

| More interesting question is:
| 
| Could the C++ front end be modified to make it compilable with any C 
| compiler (ignoring for the moment that parts of the C++ front end are now 
| written in ISO c90).  That is, how many gnu extensions are used, and can 
| they be easily removed?

I have no idea of how many GNU extensions there are.  Your question is
probably one of the most important ones to answer. 

-- Gaby

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Pop Sébastian <pop@gauvain.u-strasbg.fr> writes:

| On Tue, Mar 04, 2003 at 11:04:32AM +0100, Gabriel Dos Reis wrote:
| > Nathanael Nerode <neroden@twcny.rr.com> writes:
| > |  You want to build GCJ, so you have 
| > | to put it into stage3.  This means that stage2 and stage3 are compiled 
| > | with different options, so they can't be compared.  In order to do a 
| > | bootstrap comparison, you need to go to stage 4. 
| > 
| > The point is that in effect, comparaison is -not- bootstrapping the
| > Java compiler.  It is testing the C compiler (optionally C++ in the
| > Java case).
| > 
| Agree.
| 
| Stage4 could build only GCJ and diff object code of GCJ stage4 against GCJ stage3.  
| This will test that stage2 G++ builds verify.cc the same way stage3 G++ builds it.
| In other words we bootstrapped G++.

Thanks for putting it in better words than I.

-- Gaby

Re: Putting C++ code into gcc front end

[Richard Earnshaw]

> (Apologies if this is what's already proposed / already refuted - only
> have time to skim gcc mail.)
> 
> Could we build the C++ compiler as a 'stage 1a', carrying over the C/Ada
> compilers from stage 1?
> 
>   * stage 1:  use cc to build xgcc, cc1 and gnat1
>   * stage 1a: use stage 1 to build cc1plus
>   * stage 2:  use 1's xgcc, cc1 and gnat1 and 1a's cc1plus to build
> stage 2
>   * stage 3:  use stage 2 to build stage 3
> 
> The only issue here is if we can link the cc-built libbackend into the
> code built with stage1 xgcc - but that's almost always true and saves us
> a back-end rebuild versus four complete stages.
> 
> Or we could make it 2a:
> 
>   * stage 1:  use cc to build xgcc, cc1 and gnat1
>   * stage 2:  use stage 1 to build xgcc, cc1 and libbackend.a
>   * stage 2a: use stage 2's output to build cc1plus
>   * stage 2b: build remainding front-ends and runtimes using stages 2 +
> 2a
>   * stage 3:  use stages 2, 2a and 2b to build stage 3
> 
> In this case it's pointless comparing the c++ frontend objects in the
> bootstrap since they were all built using stage 2's cc1 - unless you
> repeat 2a and 2b as 3a and 3b. But I don't think that's necessary.
> 

It's not as simple as this.  Any non-trivial use of c++ is likely to 
require building libstdc++ first.  Currently that isn't done until the 
bootstrap phase has completed.  Not an insurmountable problem, just a 
problem.

More interesting question is:

Could the C++ front end be modified to make it compilable with any C 
compiler (ignoring for the moment that parts of the C++ front end are now 
written in ISO c90).  That is, how many gnu extensions are used, and can 
they be easily removed?

If this could be done then (assuming the libraries could be rearranged) 
then C++ could be built during stage1 and we would have a functioning 
bootstrap model again.

RE: Putting C++ code into gcc front end

[Rupert Wood]

(Apologies if this is what's already proposed / already refuted - only
have time to skim gcc mail.)

Could we build the C++ compiler as a 'stage 1a', carrying over the C/Ada
compilers from stage 1?

  * stage 1:  use cc to build xgcc, cc1 and gnat1
  * stage 1a: use stage 1 to build cc1plus
  * stage 2:  use 1's xgcc, cc1 and gnat1 and 1a's cc1plus to build
stage 2
  * stage 3:  use stage 2 to build stage 3

The only issue here is if we can link the cc-built libbackend into the
code built with stage1 xgcc - but that's almost always true and saves us
a back-end rebuild versus four complete stages.

Or we could make it 2a:

  * stage 1:  use cc to build xgcc, cc1 and gnat1
  * stage 2:  use stage 1 to build xgcc, cc1 and libbackend.a
  * stage 2a: use stage 2's output to build cc1plus
  * stage 2b: build remainding front-ends and runtimes using stages 2 +
2a
  * stage 3:  use stages 2, 2a and 2b to build stage 3

In this case it's pointless comparing the c++ frontend objects in the
bootstrap since they were all built using stage 2's cc1 - unless you
repeat 2a and 2b as 3a and 3b. But I don't think that's necessary.

Re: Putting C++ code into gcc front end

[Andreas Schwab]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

|> To correct your scheme, here is how it could proceed:
|> 
|>  * Use stage1 to build G++:
|>      + build g++ (which becomes a stage2 compiler)
|>      + use stage2 g++ to build the C++ runtime system.
|>        This step is part of using stage2 xgcc to build the full
|>        compiler. 
|> 
|> No trouble.

That requires moving bootstrap up from the gcc subdirectory to the
toplevel, which I believe is a major step.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Putting C++ code into gcc front end

[Pop Sébastian]

On Tue, Mar 04, 2003 at 11:04:32AM +0100, Gabriel Dos Reis wrote:
> Nathanael Nerode <neroden@twcny.rr.com> writes:
> |  You want to build GCJ, so you have 
> | to put it into stage3.  This means that stage2 and stage3 are compiled 
> | with different options, so they can't be compared.  In order to do a 
> | bootstrap comparison, you need to go to stage 4. 
> 
> The point is that in effect, comparaison is -not- bootstrapping the
> Java compiler.  It is testing the C compiler (optionally C++ in the
> Java case).
> 
Agree.

Stage4 could build only GCJ and diff object code of GCJ stage4 against GCJ stage3.  
This will test that stage2 G++ builds verify.cc the same way stage3 G++ builds it.
In other words we bootstrapped G++.

	Sebastian

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Nathanael Nerode <neroden@twcny.rr.com> writes:

| >No, that does not follow: We never actually bootstrap for the C++
| >compiler. Currently, we only bootstrap the C compiler and and diff the
| >objets. That does not act as a test that the C++ compiler works.  It
| >just does test the C compiler.
| This is correct but irrelevant.

Sure it *is* relevant to the overall discussion.

| >To correct your scheme, here is how it could proceed:
| >
| > * Use stage1 to build G++:
| >     + build g++ (which becomes a stage2 compiler)
| >     + use stage2 g++ to build the C++ runtime system.
| >       This step is part of using stage2 xgcc to build the full
| >       compiler. 
| >
| >No trouble.
| 
| Big trouble.  You used stage1 to build G++, which is a stage2 compiler.  
| Because stage1 is a C/Ada compiler only, *and the Java front end has C++ 
| code*, there can be no stage2 GCJ.

right but what is point of having it? 
We don't do anything -useful- with it.

|  You want to build GCJ, so you have 
| to put it into stage3.  This means that stage2 and stage3 are compiled 
| with different options, so they can't be compared.  In order to do a 
| bootstrap comparison, you need to go to stage 4. 

The point is that in effect, comparaison is -not- bootstrapping the
Java compiler.  It is testing the C compiler (optionally C++ in the
Java case).

|  Got it?

You don't need to be arrogant.

-- Gaby

Re: Putting C++ code into gcc front end

[Nathanael Nerode]

>No, that does not follow: We never actually bootstrap for the C++
>compiler. Currently, we only bootstrap the C compiler and and diff the
>objets. That does not act as a test that the C++ compiler works.  It
>just does test the C compiler.
This is correct but irrelevant.

>To correct your scheme, here is how it could proceed:
>
> * Use stage1 to build G++:
>     + build g++ (which becomes a stage2 compiler)
>     + use stage2 g++ to build the C++ runtime system.
>       This step is part of using stage2 xgcc to build the full
>       compiler. 
>
>No trouble.

Big trouble.  You used stage1 to build G++, which is a stage2 compiler.  
Because stage1 is a C/Ada compiler only, *and the Java front end has C++ 
code*, there can be no stage2 GCJ.  You want to build GCJ, so you have 
to put it into stage3.  This means that stage2 and stage3 are compiled 
with different options, so they can't be compared.  In order to do a 
bootstrap comparison, you need to go to stage 4.  Got it?

--Nathanael

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Nathanael Nerode <neroden@twcny.rr.com> writes:

| Gaby wrote:
| > You don't need to install C++ first.  You just need to build C++.
| > And you have to do that anyway if you want libjava/verify.cc.
| > So that is a non-issue.
| 
| Wrong.
| 
| Currently, it works as follows in the non-native case:
| * Build a full copy of gcc, using installed C and Ada compilers.
| * Use this copy of GCC to build libraries.
| 
| This would have to be changed if the Java front end contained C++ code.
| 
| --
| In the bootstrap case it works as follows:
| * Build a C/Ada compiler, using installed C and Ada compilers.  This is 
| the stage1 xgcc.

OK.

| * Use stage1 xgcc to build a full copy of the compiler.  This is stage2 
| xgcc.

OK.

| * Use stage2 xgcc to build another full copy of the compiler.  This is 
| stage3 xgcc (and acts as a test that the C and Ada compilers work).
| 
| Here, if the Java front end contained C++ code, then stage2 xgcc would 
| need to be built with a C++ compiler.

Yes.

| Accordingly, stage1 xgcc would need to *be* a C++ compiler.

No, that does not follow: We never actually bootstrap for the C++
compiler. Currently, we only bootstrap the C compiler and and diff the
objets. That does not act as a test that the C++ compiler works.  It
just does test the C compiler.

To correct your scheme, here is how it could proceed:

 * Use stage1 to build G++:
     + build g++ (which becomes a stage2 compiler)
     + use stage2 g++ to build the C++ runtime system.
       This step is part of using stage2 xgcc to build the full
       compiler. 

No trouble.

-- Gaby

Re: Putting C++ code into gcc front end

[Nathanael Nerode]

Gaby wrote:
> You don't need to install C++ first.  You just need to build C++.
> And you have to do that anyway if you want libjava/verify.cc.
> So that is a non-issue.

Wrong.

Currently, it works as follows in the non-native case:
* Build a full copy of gcc, using installed C and Ada compilers.
* Use this copy of GCC to build libraries.

This would have to be changed if the Java front end contained C++ code.

--
In the bootstrap case it works as follows:
* Build a C/Ada compiler, using installed C and Ada compilers.  This is 
the stage1 xgcc.
* Use stage1 xgcc to build a full copy of the compiler.  This is stage2 
xgcc.
* Use stage2 xgcc to build another full copy of the compiler.  This is 
stage3 xgcc (and acts as a test that the C and Ada compilers work).

Here, if the Java front end contained C++ code, then stage2 xgcc would 
need to be built with a C++ compiler.  Accordingly, stage1 xgcc would 
need to *be* a C++ compiler.  So step one would have to become
* Build a C/C++/Ada compiler, using installed C and Ada compilers.  This 
is the stage1 xgcc.

But as Zack pointed out, the C++ front end uses GNU extensions to C, so 
it can only be built with GCC.  Accordingly, if the installed C compiler 
wasn't gcc, we'd have to add a previous step:

* Build a C compiler, using installed CC.  This is the 'stage0' gcc.

So it's quite definitely more trouble if the Java front end uses C++ 
code.

--Nathanael

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > I don't think this is much worse than the current situation where one
| > needs to have g++ + libstdc++-v3 built if one wants Java.
| 
| It's at least incrementally more trouble.  Right now, starting with
| just a C compiler, you can get a Java compiler without having to build
| and install C++ first.

You don't need to install C++ first.  You just need to build C++.
And you have to do that anyway if you want libjava/verify.cc.
So that is a non-issue.

| > And bootstrap for C++ front-end is currently an oxymoron: it is just a
| > bootstrap for the C compiler.
| 
| I consider this a feature.

Clearly, we do not have the same definition of feature.

I consider a definition of "boostrapping the C++ compiler" which just
means "bootstrapping the C compiler" a bug.

-- Gaby

Re: Putting C++ code into gcc front end

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> I don't think this is much worse than the current situation where one
> needs to have g++ + libstdc++-v3 built if one wants Java.

It's at least incrementally more trouble.  Right now, starting with
just a C compiler, you can get a Java compiler without having to build
and install C++ first.

> And bootstrap for C++ front-end is currently an oxymoron: it is just a
> bootstrap for the C compiler.

I consider this a feature.

zw

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

[...]

| 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

I don't think this is much worse than the current situation where one
needs to have g++ + libstdc++-v3 built if one wants Java.

And bootstrap for C++ front-end is currently an oxymoron: it is just a
bootstrap for the C compiler.

-- Gaby

Re: Putting C++ code into gcc front end

[Zack Weinberg]

Tom Tromey <tromey@redhat.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

Re: Putting C++ code into gcc front end

[Gabriel Dos Reis]

Tom Tromey <tromey@redhat.com> writes:

[...]

| 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 think we should abandon the idea that C++ is a second zone class
language and just use it as a primary language, which means we should
use it where it simplifies programming and where it provides better
abstraction tools than plain C.  I support your initiative.

-- Gaby

Putting C++ code into gcc front end

[Tom Tromey]

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'm sure this is a controversial idea, so I wanted to float it before
doing any of the work.


This code uses 3 C++ features of note: classes, destructors, and
exceptions.  Rewriting it in C would be unpleasant (I think I'd prefer
to try to fix the gcj verifier).  However, it does mean that it is
likely to be buildable with just about any version of g++ that is
still out there.


In case it matters, the C++ code in question is in gcc/libjava/verify.cc.
Before putting this into the front end it would require some surgery
in order to separate it from some things that are available only in
libgcj.  I'd also have to fix one (the only known) libgcj verifier bug
first (but I have to do this anyway).

Tom