A potential competitor for GCC: pcc

Oh, please.

This is nothing more than the BSDers' "we wish we weren't so dependent on GPL code" refrain.
What's sad is to see LWN fall for it.  Probably the best thing all around would be for LWN to
pull the story and try to forget.

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. 

They're just scratching an itch, nothing wrong with that. More power to 'em.

Reading a whole article that carefully uses 'pcc' and 'GCC' capitalizations gets really tiring
on the eyes.  Just call them pcc and gcc, or perhaps PCC and GCC.

(Disclaimer: I used to be a fringe contributor to GCC some time back.)

GCC is a compiler for multiple languages and for multiple platforms. It
can work as a native compiler, a cross compiler and even a crossed-native
compiler (See http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html
for the meaning of these terms). It is very difficult to quickly produce
good code under such conditions. Given that, it is amazing that it is
able to do what it does.

By its very nature, a production-quality compiler is a complex beast and
GCC is particularly complex. There are very few people qualified enough
to make significant changes to such software. Being paid to do so helps
considerably when you take the time and effort involved into account. It
is no wonder that the major contributors are employed by Red Hat, Code
Sourcery, Google, Apple, etc.

The GCC maintainers do not take a particular pleasure in removing support
for various architectures. As the compiler evolves, someone who cares
about an architecture needs to maintain the respective back-end and
regularly post the results of running the GCC test-suite to the
"gcc-testresults" mailing list (so that other maintainers can check the
health of GCC for such an architecture).

If there is no such visible proof of an architecture being maintained
and no responses to pleas of help on the GCC mailing lists to help
maintain the respective back-end, it is natural for the GCC maintainers
to assume that no one is interested in maintaining the back-end. Such a 
back-end needs to be removed to keep the code-base maintainable.

Even then, an architecture is first deprecated in a release (and an 
announcement made so that some one who cares can still offer some help)
and then removed in a subsequent release - this gives about two years
for some one who cares about the architecture to save it.

i386 is used by the vast majority of the users of GCC as well as the
companies that support GCC, so it is not surprising that it is in the
best shape. There is no conspiracy to turn it into a "commercial"
compiler with support only for i386.

Having said that, some of the criticisms are valid.

GCC is indeed getting more and more complex with each release, not
to mention slower and slower. As with any complex software, it is easier
to add new features or fix bugs that your customers care about than
spend time and effort refactoring it and making it faster (but amazingly,
such work still happens with GCC).

GCC is intentionally not "modular" with parts that can be cleanly
separated and used because RMS was afraid that nefarious people would
be able to use this to subvert the GPL. In fact, for the same reason,
he was opposed for some time to the idea of the Java compiler (GCJ)
being able to produce JVM byte-code. Fortunately, good sense prevailed.

As GCC adds more and more front-ends and back-ends, it becomes more and
more difficult to ensure that your patch does not break anything. The
GCC bootstrapping process and its regression suite takes longer and longer.
This raises the barrier for anyone contemplating to contribute to GCC.
Perhaps GCC should just go back to being a good C/C++ compiler.

Someone has to explain to me how is gcc a monopoly. 

It looks more like an open market to me: anybody can contribute, fork... Nobody was ever
forced to use gcc.

It is shame that the TenDRA compiler does not get more interest (http://www.tendra.org/). It
is BSD licensed, multi-platform and multi-language. It's intermediate format is based on ANDF
(http://en.wikipedia.org/wiki/ANDF). It was a brilliant idea that was released as open source
just too late to make a difference. 

One of the main aims of TenDRA was to enable the distribution of applications and libraries in
the intermediate format. The intension was to have 'installers' on each target platform that
could compile the portable intermediate format into the target op-code. This would enable a
single 'compiled' distribution of applications for all platforms that had a TenDRA installer.

(I declare an interest, I worked on the original TenDRA team at the UK Defence Evaluation and
Research Agency in Malvern).

Richard

It is no little program!

gcc is probably bigger than linux. Sure linux has more lines of code but most of that is
device drivers, so a user at a given time only uses about 5% of the total of the kernel.

Also, the kernel's job is to talk to the hardware. The job of a compiler is to find the
optimal machine code representation of a C (C++, etc) program. This is a rather unsolvable
problem and it is simply constantly improved over the years.

It would be probably easier to write an operating system better than linux/BSD than a compiler
better then gcc.

OK. Some times gcc devs are too concerned with the SPEC benchmarks (which is a red herring
imho), but at least they believe in free software.