GCC unplugged

As long as it is compatible with mesa what is the problem ? (I think there are plans to use
llvm (BSD licencsed) with mesa).

Well, yes, the desire for a BSD-licensed compiler above all else *is* the 
only sane reason for anyone to pick up the compiler they did.

If they'd wanted an extensible high-quality free compiler, there are some 
other than GCC which they could have picked up instead which are *far* 
more capable than the ancient thing they chose to go with. (LLVM provides 
most of the pieces needed on its own, but ooh, the license is wrong, 
sheesh.)

Oh, and the code is a good bit less ugly nowadays. You might want to look 
into developments in GCC in the last eight years or so. It's not been 
static by any means. (The whole plugin discussion has been triggered in 
part because inter-module optimizations require the writing out of a lot 
of GCC internal state anyway, in some form, and RMS has okayed this. He's 
not totally inflexible, you see, although it is true that in this area he 
*has* probably been too inflexible.)

> GCC needs to get out of the mindless, frothing-mouthed, 
> fear-induced restrictions 

The only person I see frothing at the mouth isn't with GCC.

You are very good at quoting other FUD-spreaders about the problems with GCC.

Some of your remarks are unfortunately quite true: GCC has turned into a horrible slow
compiler in recent years.  However, "the huge mess of cryptic code" is a half-truth (the best
kind of lie!).  I wonder if you've ever looked at the source code of a GCC release newer than,
say, GCC 3.3.

First of all, much of the 1990s cruft is gone.  GCC suffered badly under some of the
FSF-appointed maintainers in the 1990s, because these maintainers were unwilling to accept
patches that implemented technology that other compilers adopted in that decade. Think lazy
code motion and SSA, in particular.  However, after the egcs fork, things improved greatly;
and with tree-ssa, at least half of the GCC middle end is as good as any other compiler's.
For example, GCC's auto-vectorization implementation is recognized as the best in the industry,
and the alias analysis implemented for tree-ssa is state of the art.

Second, the ugly code: Yes, it is there, that's indisputable.  But it is not really much worse
than what other production compilers have to offer.  Production compilers are crufty.  Always.
Believe me, I've seen a few.

It takes many years to rework a compiler, and longer for a compiler that has basically
suffered from neglect.  A lot of the rotten GCC code from the 1980s 1990s has been removed,
and modernization of the rest of the compiler is still ongoing (think register allocator, in
particular).  But you can't just rework a production compiler overnight, especially not one
that has to support 100s of different CPU variants.

Having said all that, I agree that GCC is still too political.  The originators of the egcs
fork are still "in charge" of the political side of GCC, 10 years after the fork, and what
they do, and what the FSF does, is not transparent.  I was never able to understand why GCC
can't just go on without the FSF, which looks like nothing but a burden to me.  The recent
discussion about plugins is just one recent example.  People may also remember the discussions
about serializing the internal representation for link-time optimizations.  Other production
compilers have been able to do this since the late 1980s.  For GCC, work on this has started
only recently.  This is another example of how the FSF helps GCC into almost-irrelevancy.

Most of the comparisons of GCC with LLVM don't make sense to me.  LLVM is new and therefore
not *yet* crufty.  LLVM has an excelent basic infrastructure, but it still can't do many of
the things that GCC can do.  A couple of years from now it will just be as complex as GCC.
And in any case, at least to me the thought of a compiler controlled by Apple is not appealing
;-)

Your remarks about "invalid code generation bugs in GCC" are just naive.  All compilers have
bugs, and I think it's safe to assert that GCC has fewer bugs than most other compilers.
To me it seems that some linux kernel developers like to bash GCC just for the sake of it.
The more you complain about GCC on lkml, the higher your karma score goes.  The compile time
complaints are valid, but if they know so well how things *should* be, then why don't they
help out?  There are kernel hackers that are also GCC maintainers with the highest
review/commit privileges.  Yet, I rarely see them contribute to the development of GCC. There
are 1000s of kernel developers (many of them paid) and only about a dozen full-time GCC
developers.  Considering the lack of resources, I think GCC improves at an impressive rate.

GCC is a favorite bashing target for many people.  I wish there would be some more respect and
understanding for the complexity of compilers, especially for one that laid the foundation for
the existence and success of free/open source software, and continues to be a key tool for
most open source software projects.

Would it be a bad thing if GCC suffered the same fate as XFree86? A project which had been
gridlocked and stagnant became much more exciting very suddenly, attracted a lot of developer
attention and rapidly met a lot of goals that had been on people's wishlists for ages.

In fact, this happened in the late 90s, when egcs forked off of GCC and eventually the
non-fork was abandoned and egcs was officially adopted going forward. As far as I can tell,
this allowed GCC to be largely rewritten with a different design without exposing end users to
a compiler that didn't yet work, followed by a sudden leap forward in GCC capabilities when
the egcs version was strictly better than the old fork and replaced it.

"A lot of the fears about the creation of proprietary modules could be relieved by an explicit
warning that any use of the plugin interface will be considered the creation of a derivative
work and thus subject to the GPL."

That would probably secure GCC enough regarding proprietary plugins. That would require an
extended GPL license.

>A lot of the fears about the creation of proprietary modules could be relieved by an explicit
warning that any use of the plugin interface will be considered the creation of a derivative
work and thus subject to the GPL.

Well... yes, that'd solve the problem, if it worked.  Unfortunately, copyright doesn't work
that way.  Only a judge can decide what is or what isn't derivative work.  If they're going to
slap a label like that on, they might as well put all their other wishes in too, like
"software compiled with this compiler not subject to DMCA restrictions", "this compiler
removes all patents as it works"...

"Where does such flexibility make sense for compilers?"

I respectfully submit that you're not thinking outside the box enough.  An example I know of
that would benefit from a pluggable GCC is GCC-XML (http://www.gccxml.org), which has the
(limited, last I looked) capability of exposing part of the GCC internal representation as
XML.  No, I'm not an XML fanboy, but the wide array of XML tools that can be applied make code
transformations a great deal more **accessible to the average developer**.  I understand the
GCC-XML team had very deliberate push-back from the core GCC devs on integrating their work
precisely because of the "easing proprietary extensions" specter.  As a result, GCC-XML is
indeed a largely duplicate download of plain GCC.

This is just one example, though.  Perhaps you'd want to make better integration with a
debugger, farm out pieces to a co-processor, generate some fancy-schmancy metrics and graphs
for the suits... and on and on.  I don't think either of us can imagine all the possibilities.

All this notwitstanding, sure, an internal cleanup and better documentation would go a long
way towards attracting development energy.  It is, no doubt, "a staggeringly sensible idea,"
but other efforts to make GCC development accessible more approachable are pretty far along
the sensibility curve in my book, too.

The passes system would actually make it, hm, `more possible' to add plugins. It's just that
not every significant transform that affects properties of the IR is reflected in properties
visible to the passes system, and it would be really easy for a plugin author to screw up the
data flowing through the translation pipeline in subtle ways.

At the very least a pipeline author should (just as the author of any other GCC change) run
the testsuite after changing anything significant. And that takes hours, much longer than
recompiling the compiler itself, especially if you avoid building/testing libjava. If you're
doing that, yo may as well build the compiler too, negating the advantage of plugins.

Plus, a lot of things are still implemented by means of target-specific macros rather than
function pointers; those are not used so much in the front- and middle-end code, but that
doesn't mean they're not used at all. (This is a good ideal state to aim for, though its speed
impact if everything was so translated might be substantial. Some of those macros are called a
*lot*. We probably need memory-efficient IPA before this is practical, so we can turn them
into functions and then inline them across translation units, although even that would fail if
they had to be replaceable at runtime... right now compiling GCC with --combine runs every
machine I have access to out of memory, so that's not ready for prime time yet. Mind you my
largest box has only 1.5Gb of RAM and some of that is used for other things.)


GCCXML is the largest plus point of all this, really. I've often wanted to be able to suck
data out of GCC's IR, because GCC has already done a lot of analysis of the source for me, and
I'd rather not reproduce all that work when writing little source code auditing and
invariant-checking tools. RMS's concerns about proprietary consumers of that data are
increasingly irrelevant, IMNSHO: there are lots of proprietary systems which do similar things
already, and anyone wanting to use GCC to do it and with the skill to know what they're asking
for has the skill to add an export-bits-of-IR feature to GCC --- which they are of course
allowed to do, under the GPL. So this is really security-by-obscurity on RMS's part, which
depends on the insides of GCC remaining too obscure to easily modify: and obscure and
hard-to-modify internals are exactly what the GCC maintainers *don't* want (or at least I hope
they don't).

The copyright assignment requirement really *is* worthwhile and really *does* have advantages,
not least that GCC can be relicensed when needed (which the FSF recently took advantage of).

It would be rather silly if flagship FSF projects couldn't be relicensed to use the latest
versions of the FSF's own licenses.

(In any case, you lose no rights to speak of with the copyright assignment anyway: you get a
grantback which gives you back the rights you'd have as a copyright owner anyway, including
the right to release your own work under whatever license you choose, free or not.)

Also, the majority of GCC maintainers don't work for free (either they're paid by people who
need GCC --- Linux distros, Apple, et seq --- or they run consultancies based on adapting and
porting GCC for people --- e.g. CodeSourcery). This has been true for a *long* time: not quite
for all of GCC's existence, but certainly for most of it.

In response to:
"All that said, this is all second or third hand, and nobody seems to have an actual record of
RMS, or anyone else who can speak for the FSF or GCC, actually stating that a plugin
architecture should not be done because it would make proprietary extensions easier.  Until
there's any clear proof of that, we have to give the FSF the benefit of the doubt."

Please see:
http://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
"Anything that makes it easier to use GCC back ends without GCC front
ends--or simply brings GCC a big step closer to a form that would make
such usage easy--would endanger our leverage for causing new front
ends to be free.

Because of this, the GNU Project will in all probability not install
such changes, should they be available.  This statement reflects a
firm conclusion based on a decade of thought."

GCC uses versioned interfaces where appropriate (e.g. libgcc, libstdc++ and libjava), but
using versioned interfaces inside the compiler itself seems likely to be both fantastically
annoying and very slow. We're not talking coupling of the level of `struct stat' here; we're
talking passes that read and modify elaborate data structures which gain and lose properties
as they flow through different passes. How on earth would you propose versioning the tree
representing a C++ function? What if someone inserts a pass in the middle which accepts an
older version and transforms it? The later passes would expect the later version, but it's not
there anymore! (This is doubly true if the representation changes in major ways.)

No, this is much too much trouble. There are some things it makes sense to version. Parse
trees and intermediate language structures is not one of them.