Grumbling about the compiler, its speed and the code it generates has been heard for every
compiler since the first one. In particular, this compiler won't produce better code than GCC;
the goals of simpler, more backward compatible and less emphasis on a few important processors
make it hard to generate faster code for most people.
Some of Marc's complaints have point, but maintaining a multi-platform, multi-CPU compiler is
hard. The kernel to kernel comparisons between Linux, NetBSD, OpenBSD and FreeBSD didn't look
great for OpenBSD and NetBSD; it's hard to compete if you don't have enough maintainers. If
the maintainers for this compiler can create a working compiler that compiles real C (not just
"many of the BSD userspace programs", all of them plus user programs) that targets all the
processors they need, will they manage to follow the C standard and produce reasonably fast
code and good warnings? (I'm really curious if PCC will actually produce better warnings, or
if they will just pick a different set of false negatives and false positives and declare it
better.)
Also, at least some of the blame of the problems with platforms becoming unsupported is that
nobody was testing the compiler on these platforms. Perhaps being closer to the BSD community,
the PCC developers will manage to find people to test PCC, but if Marc Espie can find testers
for PCC, he could have found testers for GCC.
Furthermore, I find it unlikely that they even plan to produce a full competitor for GCC; most
likely C++ will still require GCC, and despite the kibitzing, there will be platforms, both
non-BSD OSes and CPUs the *BSDs don't run on, that GCC targets and will continue to target
that PCC won't.