better alternatives fast approaching

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.