Compilers in OpenBSD

A decent picture of the history is given in the OP:<p>* &quot;gcc 2.5 (at the time) had a few bugs, but not many&quot;<p>* &quot;schism between gcc 2.8, conservative...and the ``Pentium gcc&#x27;&#x27; group...[Pentium gcc group was] stretching the optimizer code beyond its limits&quot;<p>* &quot;These projects eventually merged as gcc 2.95...gcc [now] had bugs&quot;<p>But what does this historical lesson tell us?<p>Stallman was conservative, slow-moving and cathedral-like with 2.8. This approach helped keep bugs out of the code.<p>The &quot;pentium gcc&quot; (Cygnus&#x2F;egcs) group was quickly responding to marketplace needs. It was more bazaar-like. It committed code more freely than Gnu would - and the code while allowing for new functions was not always that well architected.<p>So what was the deal with this schism and then subsequent merger which happened? What happened was egcs (the Cygnus-oriented one, the &quot;pentium gcc&quot; one) began eclipsing gcc. Toward the end it <i>really</i> began eclipsing gcc. It was not as solid as gcc, but it had all the new functionality people wanted. All over, people were seriously about to abandon gcc and go with egcs. At this point Stallman threw up his hands and accepted that the egcs approach had won. They merged, and gcc became more liberal about what code it would commit, at the expense of being a solid code base. Just like the OP says.<p>So now what is different this time around? Why is a compiler which prioritizes stability and correctness over new functionality and optimizations going to win? The latter approach won last time around, why should the first approach win this time? Especially since in battles between cathedral&#x2F;waterfall projects and bazaar&#x2F;agile projects, the bazaar&#x2F;agile approach seems to come out on top again and again. OpenBSD can afford to go this route if it wants because OpenBSD fills a marginal niche. It might even be interesting to watch OpenBSD go down this road. But for more mainstream OS&#x27;s like Linux, this approach might not be possible.<p>And if anyone mentions Apple - Apple is not marginal, but it is a niche. GCC and Linux are in a multitude of environments. A company like Apple with its own ecosystem and only a handful of targets can afford to pick and choose its compiler.

Ok, that is a pretty compelling argument in favor of non-open source software.<p>I read it to say that GCC is so open source that it cannot converge on a stable release. Further there isn&#x27;t a non-commercial (aka free) incentive for making it stable, so it doesn&#x27;t converge. Rather it trundles along from new optimization strategy to the next constantly in a state of minor bugginess. The economics of &#x27;sold&#x27; products uses the loss of revenue as the incentive to maintain quality, without that incentive its hard.<p>Google has (had?) a pretty good sized team that did nothing but maintain GCC. I&#x27;m sure it cost them easily $1M&#x2F;year to keep that team going. There is no incentive for them to fund a team like that in a third party such that everyone else benefits from their work. Sure they offer the changes back into the base product, and somewhere else there is another team working for company Y that is taking those, porting them into their effort. In this article from Marc he mentions himself and 5 other developers who are the &quot;compiler people&quot;. 5 developers, $120K each, that is .6M&#x2F;year before you add insurance and office space.<p>And those 5 have their lives made more difficult by the dozen or so folks who are committing in changes that destabilize parts of the code or require side ports.<p>It makes me wonder how many people there are like me who would be willing to pay $100&#x2F;year for a bespoke C compiler that was supported by a single source and stable.

For an example of a recent bug try this <a href="http://gcc.gnu.org/bugzilla//show_bug.cgi?id=56888" rel="nofollow">http:&#x2F;&#x2F;gcc.gnu.org&#x2F;bugzilla&#x2F;&#x2F;show_bug.cgi?id=56888</a> basically the compiler tries to recognise code that manually does memcpy or memcmp and replaces it with the built in version. Even if you are trying to compile libc where you get an infinite loop when this happens.

No mention of pcc[1] except note that it was orphaned in the early 90s. I see here[2] it&#x27;s been removed from OpenBSDs base system. What happened to pcc? I had high hopes for it. Is there no chance it&#x27;d become a viable compiler? (fwiw, it&#x27;s still included in NetBSD base system).<p><pre><code> [1] http:&#x2F;&#x2F;pcc.ludd.ltu.se&#x2F; [2] http:&#x2F;&#x2F;comments.gmane.org&#x2F;gmane.os.openbsd.misc&#x2F;196817</code></pre>

&gt;The last de-facto LTS compiler we have had was gcc 2.7.2.1<p>The new de-facto LTS compiler is gcc 4.2.1, the last version released under GPLv2. After gcc switched to GPLv3, Apple and FreeBSD stayed on 4.2.1.

&quot;...but there is something I wish would happen first.<p>An LTS release of an open source compiler.&quot;<p>Surprising that this doesn&#x27;t already exist--Apple and RedHat and Ubuntu, etc. must all maintain what is in effect a LTS version of the compilers they ship, in the same way that OpenBSD does.

I&#x27;m curious why compiler testing appears to be so hard. It seems to me that: Given this C input, this AST should be built, and on this platform, this code should be generated. This should be testable through automated scripts and numerous test cases could be created for new features resulting in huge regression suites. Am I missing something, or is it the effort of putting together such tests that&#x27;s the problem?

The only software that isn&#x27;t buggy is dead software with no users. All software has bugs, and that is a fact of life.<p>Clearly OpenBSD developers haven&#x27;t been involved with the compiler engineering communities, and their wishes have been neglected over many years; this is not news. Why? Because there are no _users_. Bugs don&#x27;t get fixed by bitching about them: they get fixed when you get involved with upstream and write patches.<p>GCC can be as &quot;conservative&quot; or &quot;cathedral-like&quot; as it wants: if it does not produce sufficiently optimized code for the big users, it will be thrown out the window. Today, GCC is in active development and has more users than anyone else. The leadership is strong: RMS and many of the GNU people are heavily involved. Those are the facts.<p>LLVM is the other elephant in the room: from my experience posting patches on their list, they don&#x27;t give a shit about getting llvm&#x2F;clang to build linux.git, or many of the projects that currently use GCC. Although it might be technically superior (the code is much more readable and maintainable), the community is much too narrow. Moreover, the leadership is gone: most of the top contributors (Chris Lattner, Evan Cheng, Reid Spencer) seem to have lost interest in the project.<p>The proprietary compilers like ICC are mostly useful just in research. Sure, they produce highly optimized code, but they&#x27;re black boxes that cannot be studied or tinkered with. I tried compiling git.git with ICC a few years ago out of curiosity [1]: pages and pages of totally pointless warnings; gcc and clang both clean-compiled git.git at that point.<p>What the community needs is a compiler project with a strong leadership that cares deeply about its users, not a dead &quot;LTS&quot; project that nobody else gives a shit about: nobody wants to work on a project that&#x27;s in maintenance-mode. Hardware, programming languages, and compilers evolve constantly, and programmers must learn to cope with these changes.<p>Fwiw, I&#x27;d really like to see what &quot;bugs&quot; this guy is talking about. If they really don&#x27;t care about hardware, programming language, and compiler technology advancement, why don&#x27;t they just maintain a port of an older version of GCC? Why bother with new versions at all?<p>[1]: <a href="https://gist.github.com/anonymous/1367335" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;anonymous&#x2F;1367335</a>

Refreshing to know that even settled projects have those same problems at their core. Depending on upstream developers is always a big risk you have to calculate well. Was always a pain and only gets bigger in our agile *aaS world.

The g++ 4.7 and or libstc++ that goes with it from their pkg-add repo is b0rked at the moment. Exceptions don&#x27;t work.

If people switch from GCC to Clang&#x2F;LLVM in enough numbers that Apple think they can get away with it, Apple will, in a heartbeat, close the development of Clang&#x2F;LLVM and make all new versions proprietary.

It seems like they might like CompCert. An optimizing C compiler that comes with a formal proof of correctness. Downsides: GPL, doesn&#x27;t quite implement the full C language (but it&#x27;s getting closer), and no support for ancient crap such as m88k.<p>EDIT: I misunderstood the license file, the majority of the code is non-commercial-use only, only a small part is dual-licensed. Still a cool project, even if it&#x27;s not open source...

I love seeing posts like this from OpenBSD team members. I cut my chops developing on that platform and I have to say I&#x27;ve never encountered a more clean and well thought-out code base.

Hopefully the OpenBSD members will reach out to the FreeBSD members, who can share a lot of knowledge about their transition from GCC in the base system, over to Clang&#x2F;LLVM.

Why not just to have clang installed in &#x2F;usr&#x2F;local?) And gcc 4.2.1 is good-enough.

People seeing the value of correctness. Proofs &gt;&gt; Tests.