public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Putting C++ code into gcc front end
@ 2003-03-05 21:07 Benjamin Kosnik
  2003-03-05 22:18 ` Zack Weinberg
  0 siblings, 1 reply; 134+ messages in thread
From: Benjamin Kosnik @ 2003-03-05 21:07 UTC (permalink / raw)
  To: gcc; +Cc: austern

> 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.

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-08 19:23 Robert Dewar
  0 siblings, 0 replies; 134+ messages in thread
From: Robert Dewar @ 2003-03-08 19:23 UTC (permalink / raw)
  To: guerby, neil; +Cc: bosch, gcc, geoffk, per, tromey

> 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.

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-08 19:00 Robert Dewar
  0 siblings, 0 replies; 134+ messages in thread
From: Robert Dewar @ 2003-03-08 19:00 UTC (permalink / raw)
  To: geoffk, neil; +Cc: gcc, per, tromey

> > > 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.

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-06 20:36 Nathanael Nerode
  0 siblings, 0 replies; 134+ messages in thread
From: Nathanael Nerode @ 2003-03-06 20:36 UTC (permalink / raw)
  To: gcc

Tim Josling said:

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

--Nathanael

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-06 20:23 Tim Josling
  0 siblings, 0 replies; 134+ messages in thread
From: Tim Josling @ 2003-03-06 20:23 UTC (permalink / raw)
  To: gcc

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.


^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-06 17:17 Joern Rennecke
  2003-03-06 18:25 ` Richard Earnshaw
  0 siblings, 1 reply; 134+ messages in thread
From: Joern Rennecke @ 2003-03-06 17:17 UTC (permalink / raw)
  To: Richard Earnshaw; +Cc: Olivier Galibert, Gabriel Dos Reis, Rupert Wood, gcc

> > > 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

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-05 23:03 Robert Dewar
  2003-03-06  7:18 ` Gabriel Dos Reis
                   ` (2 more replies)
  0 siblings, 3 replies; 134+ messages in thread
From: Robert Dewar @ 2003-03-05 23:03 UTC (permalink / raw)
  To: gcc, kgardas

> 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.

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-05 22:42 Chris Lattner
  0 siblings, 0 replies; 134+ messages in thread
From: Chris Lattner @ 2003-03-05 22:42 UTC (permalink / raw)
  To: gcc; +Cc: Karel Gardas


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/

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-05 16:20 Robert Dewar
  2003-03-05 16:31 ` Gabriel Dos Reis
  2003-03-05 21:28 ` tm_gccmail
  0 siblings, 2 replies; 134+ messages in thread
From: Robert Dewar @ 2003-03-05 16:20 UTC (permalink / raw)
  To: gdr, zack; +Cc: dewar, gcc, mrs, tromey

>   * 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

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-05  4:27 Robert Dewar
  2003-03-05  7:00 ` Zack Weinberg
  0 siblings, 1 reply; 134+ messages in thread
From: Robert Dewar @ 2003-03-05  4:27 UTC (permalink / raw)
  To: gdr, mrs; +Cc: gcc, tromey

> > 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.

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-04 18:14 Nathanael Nerode
  2003-03-04 18:21 ` Zack Weinberg
  0 siblings, 1 reply; 134+ messages in thread
From: Nathanael Nerode @ 2003-03-04 18:14 UTC (permalink / raw)
  To: gcc

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

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-04 17:55 Benjamin Kosnik
  2003-03-04 20:02 ` Matt Austern
                   ` (2 more replies)
  0 siblings, 3 replies; 134+ messages in thread
From: Benjamin Kosnik @ 2003-03-04 17:55 UTC (permalink / raw)
  To: gcc


> 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

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-04 17:30 Benjamin Kosnik
  0 siblings, 0 replies; 134+ messages in thread
From: Benjamin Kosnik @ 2003-03-04 17:30 UTC (permalink / raw)
  To: gcc


> 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

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-04 17:29 Benjamin Kosnik
  0 siblings, 0 replies; 134+ messages in thread
From: Benjamin Kosnik @ 2003-03-04 17:29 UTC (permalink / raw)
  To: gcc


> 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

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-04 16:56 Nathanael Nerode
  0 siblings, 0 replies; 134+ messages in thread
From: Nathanael Nerode @ 2003-03-04 16:56 UTC (permalink / raw)
  To: gcc

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

^ permalink raw reply	[flat|nested] 134+ messages in thread
[parent not found: <616BE6A276E3714788D2AC35C40CD18DAD4FC1@whale.softwire.co.uk>]
* Re: Putting C++ code into gcc front end
@ 2003-03-04 10:19 Nathanael Nerode
  2003-03-04 10:23 ` Gabriel Dos Reis
  0 siblings, 1 reply; 134+ messages in thread
From: Nathanael Nerode @ 2003-03-04 10:19 UTC (permalink / raw)
  To: gcc


>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

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Re: Putting C++ code into gcc front end
@ 2003-03-04  9:53 Nathanael Nerode
  2003-03-04 10:06 ` Gabriel Dos Reis
  0 siblings, 1 reply; 134+ messages in thread
From: Nathanael Nerode @ 2003-03-04  9:53 UTC (permalink / raw)
  To: gcc

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

^ permalink raw reply	[flat|nested] 134+ messages in thread
* Putting C++ code into gcc front end
@ 2003-03-04  3:06 Tom Tromey
  2003-03-04  5:45 ` Gabriel Dos Reis
                   ` (2 more replies)
  0 siblings, 3 replies; 134+ messages in thread
From: Tom Tromey @ 2003-03-04  3:06 UTC (permalink / raw)
  To: GCC Hackers

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

^ permalink raw reply	[flat|nested] 134+ messages in thread

end of thread, other threads:[~2003-03-08 17:37 UTC | newest]

Thread overview: 134+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-05 21:07 Putting C++ code into gcc front end Benjamin Kosnik
2003-03-05 22:18 ` Zack Weinberg
2003-03-06  9:13   ` Olivier Galibert
2003-03-06 11:08   ` Richard Earnshaw
2003-03-06 17:27   ` Alexandre Oliva
  -- strict thread matches above, loose matches on Subject: below --
2003-03-08 19:23 Robert Dewar
2003-03-08 19:00 Robert Dewar
2003-03-06 20:36 Nathanael Nerode
2003-03-06 20:23 Tim Josling
2003-03-06 17:17 Joern Rennecke
2003-03-06 18:25 ` Richard Earnshaw
2003-03-07 19:04   ` Toon Moene
2003-03-05 23:03 Robert Dewar
2003-03-06  7:18 ` Gabriel Dos Reis
2003-03-06  7:53 ` Karel Gardas
2003-03-06  9:17   ` Gabriel Dos Reis
2003-03-06 17:25 ` Alexandre Oliva
2003-03-06 22:23   ` Michael Matz
2003-03-06 22:30     ` Karel Gardas
2003-03-06 22:52     ` Gabriel Dos Reis
2003-03-06 23:31       ` Michael Matz
2003-03-05 22:42 Chris Lattner
2003-03-05 16:20 Robert Dewar
2003-03-05 16:31 ` Gabriel Dos Reis
2003-03-05 18:52   ` Matt Austern
2003-03-05 21:20     ` Toon Moene
2003-03-05 21:28 ` tm_gccmail
2003-03-05 21:29   ` Fabio Alemagna
2003-03-05 22:12   ` Karel Gardas
2003-03-06 12:39     ` Andrew Haley
2003-03-06  7:58   ` Lars Segerlund
2003-03-06 11:47     ` Vladimir Merzliakov
2003-03-05  4:27 Robert Dewar
2003-03-05  7:00 ` Zack Weinberg
2003-03-05  7:57   ` Gabriel Dos Reis
2003-03-05 19:18     ` Mike Stump
2003-03-04 18:14 Nathanael Nerode
2003-03-04 18:21 ` Zack Weinberg
2003-03-04 18:28   ` Geert Bosch
2003-03-04 19:35     ` Zack Weinberg
2003-03-04 17:55 Benjamin Kosnik
2003-03-04 20:02 ` Matt Austern
2003-03-04 20:08   ` Gareth Pearce
2003-03-04 21:50 ` Michael Matz
2003-03-05  8:48   ` Lars Segerlund
2003-03-05  9:40     ` Tom Lord
2003-03-04 22:02 ` Gabriel Dos Reis
2003-03-04 17:30 Benjamin Kosnik
2003-03-04 17:29 Benjamin Kosnik
2003-03-04 16:56 Nathanael Nerode
     [not found] <616BE6A276E3714788D2AC35C40CD18DAD4FC1@whale.softwire.co.uk>
2003-03-04 11:55 ` Rupert Wood
2003-03-04 12:11   ` Richard Earnshaw
2003-03-04 12:46     ` Gabriel Dos Reis
2003-03-04 13:57       ` Olivier Galibert
2003-03-04 14:21         ` Lars Segerlund
2003-03-04 14:33         ` Richard Earnshaw
2003-03-04 14:46           ` Olivier Galibert
2003-03-04 14:53             ` Richard Earnshaw
2003-03-04 15:03               ` Gabriel Dos Reis
2003-03-04 15:11                 ` Olivier Galibert
2003-03-04 15:19                   ` Richard Earnshaw
2003-03-04 15:26                   ` Gabriel Dos Reis
2003-03-04 16:30                     ` Kaveh R. Ghazi
2003-03-04 17:17               ` Steven Bosscher
2003-03-04 17:41                 ` Phil Edwards
2003-03-04 18:37                   ` Daniel Berlin
2003-03-05 10:51                 ` Joseph S. Myers
2003-03-05 18:48                   ` Mark Mitchell
2003-03-04 17:33               ` Zack Weinberg
2003-03-04 17:53                 ` Phil Edwards
2003-03-04 20:50                   ` Geoff Keating
2003-03-04 21:01                     ` Gabriel Dos Reis
2003-03-04 22:03                       ` Geoff Keating
2003-03-04 22:49                         ` Michael Matz
2003-03-04 23:07                         ` Gareth Pearce
2003-03-05  2:13                           ` Michael S. Zick
2003-03-05  2:19                             ` Gareth Pearce
2003-03-05  0:50                         ` Diego Novillo
2003-03-04 18:26                 ` Geert Bosch
2003-03-04 21:48                 ` Michael Matz
2003-03-05  2:55       ` Mark Mitchell
2003-03-04 13:52     ` Nathan Sidwell
2003-03-04 14:22       ` Richard Earnshaw
2003-03-04 16:40         ` Nathan Sidwell
2003-03-04 18:18       ` Dale Johannesen
2003-03-04 19:25         ` Richard Earnshaw
2003-03-05 16:51         ` Marc Espie
2003-03-05 18:42           ` Dale Johannesen
2003-03-04 10:19 Nathanael Nerode
2003-03-04 10:23 ` Gabriel Dos Reis
2003-03-04 11:20   ` Pop Sébastian
2003-03-04 12:42     ` Gabriel Dos Reis
2003-03-04  9:53 Nathanael Nerode
2003-03-04 10:06 ` Gabriel Dos Reis
2003-03-04 11:25   ` Andreas Schwab
2003-03-04  3:06 Tom Tromey
2003-03-04  5:45 ` Gabriel Dos Reis
2003-03-05  0:54   ` Mike Stump
2003-03-04  7:01 ` Zack Weinberg
2003-03-04  7:12   ` Gabriel Dos Reis
2003-03-04  7:54     ` Zack Weinberg
2003-03-04  9:20       ` Gabriel Dos Reis
2003-03-04 17:35         ` Zack Weinberg
2003-03-04 15:05 ` Michael Matz
2003-03-04 15:06   ` Gabriel Dos Reis
2003-03-04 15:08   ` Lars Segerlund
2003-03-04 15:12     ` Gabriel Dos Reis
2003-03-04 15:33       ` Lars Segerlund
2003-03-04 15:58         ` Gabriel Dos Reis
2003-03-04 16:01         ` Olivier Galibert
2003-03-04 16:09           ` Kaveh R. Ghazi
2003-03-04 16:49             ` Nathan Sidwell
2003-03-04 17:18               ` Zack Weinberg
2003-03-04 21:46                 ` Michael Matz
2003-03-04 17:20         ` Andrew Haley
2003-03-04 17:36     ` Tom Tromey
2003-03-06 14:59       ` Fergus Henderson
2003-03-07  3:51       ` Per Bothner
2003-03-07 13:39         ` Pop Sébastian
2003-03-07 20:41           ` Neil Booth
2003-03-07 20:49             ` Per Bothner
2003-03-07 21:52             ` Geoff Keating
2003-03-07 21:57               ` Per Bothner
2003-03-07 22:55               ` Neil Booth
2003-03-07 22:57                 ` Geoff Keating
2003-03-07 23:05                   ` tm_gccmail
2003-03-07 23:24                     ` law
2003-03-07 23:07                   ` Neil Booth
2003-03-07 23:09                   ` Geert Bosch
2003-03-07 23:19                     ` Neil Booth
2003-03-08  0:37                       ` Steven Bosscher
2003-03-08  2:09                       ` Laurent Guerby
2003-03-08 15:27                 ` Toon Moene
2003-03-07 20:13         ` Joseph S. Myers

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).