Of Bounties and Mercenaries

Chris Lattner sabre@nondot.org
Tue Apr 6 05:32:00 GMT 2004


Andrew Pinski wrote:
> The other problem with this is that "Modern" "Standard" C++ has the
> following problems:
> 1. Makes a mess out of simplifying code from the compiling when the
> compiler is being miscompiled itself.

Huh?

> 2. "Modern" means templates see 1.

Double huh?

> 3. "Standard" means that we have to do more workarounds that Boost does,
> see 1.

No, you just require a reasonable baseline compiler, like GCC 3.x.  :)  I
realize that this is not a wonderful solution with GCC now, but that's
primarily due to the fact that it's so hard to cross compile GCC to
certain architectures.  In LLVM, it's a simple matter of saying -march=x86
or -march=sparcv9 to select a backend, so retargetting is much simpler
than in GCC.

> 4. GC will be still there just in a slightly different form, see 2 and
> 1.

Not true at all.  In LLVM we have absolutely no GC, and no need or desire
for one.  With C++ ctor/dtors and a simple ownership model, there is no
need for a GC at all.  Note that this makes performance bugs dramatically
easier to understand.

> 5. The number of bug reports about the C++ is high and we get more
> invalid  bugs each day, so we will then get bug reports about GCC not
> compiling on some C++ compiler, see 3.

This seems to be the same point as #4 above.  Perhaps you are trying to
say that not as many people know C++ as know C?

> Now if we figure out a good GC in that only parts of the compiler uses
> it, we will no longer have all the issues we currently have because the
> part I am talking about RTL (which is the most memory bounded part) will
> move from being in the GC into being malloc'd and maybe pool alloced
> instead so it will be relatively close in memory.

Hrm, this has absolutely nothing to do with C++.  In fact, this is all
about having a clear ownership model for memory (which none of the GCC IRs
have).  If nothing else, the GC introduced in GCC 3.0 made the compiler
easier to work on and understand.  It seems like taking that away, would,
well, be a huge regression in terms of GCC maintenance.

-Chris

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




More information about the Gcc mailing list