better alternatives fast approaching

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.