[Ologn]

A decent picture of the history is given in the OP:

* "gcc 2.5 (at the time) had a few bugs, but not many"

* "schism between gcc 2.8, conservative...and the ``Pentium gcc'' group...[Pentium gcc group was] stretching the optimizer code beyond its limits"

* "These projects eventually merged as gcc 2.95...gcc [now] had bugs"

But what does this historical lesson tell us?

Stallman was conservative, slow-moving and cathedral-like with 2.8. This approach helped keep bugs out of the code.

The "pentium gcc" (Cygnus/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.

So what was the deal with this schism and then subsequent merger which happened? What happened was egcs (the Cygnus-oriented one, the "pentium gcc" one) began eclipsing gcc. Toward the end it really 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.

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/waterfall projects and bazaar/agile projects, the bazaar/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's like Linux, this approach might not be possible.

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.

[fusiongyro]

Both you and Chuck see this situation as naturally arising out of some aspect of open source software. I see this as being simply a side-effect of particular compiler developers enjoying optimization more than portability. Couldn't it just be priorities on these teams that led them to this situation, without it being some kind of indirect result of some over-arching political/economic phenomenon?

[asabjorn]

I agree and as an academic I can say that optimizations are sure sell for an academic paper, and I think most new optimizations are first developed in academic work in industry or at universities. Portability on the other end seems like a hard sell and if it sounds too much like engineering it is academic suicide.

[Someone]

I don't think Apple is aiming for "a compiler which prioritizes stability and correctness over new functionality and optimizations". I haven't checked, but I would not be surprised if they have cases where the compiler shipping with Mac OS X 10.q is obsoleted before they ship Mac OS X 10.q+1 a year later. Also, I think clang was the first compiler to claim to fully support C++ 11,

As to the subject at hand: OpenBSD aims for an OS "which prioritizes stability and correctness over new functionality and optimizations". Such an OS will want to use a similar compiler. And yes, I think one can draw an analogy between gcc/egcs and BSD/Linux here.

[fafner]

> Also, I think clang was the first compiler to claim to fully support C++ 11,

GCC 4.8.1 was the first compiler with complete C++11 support. Clang with complete C++11 support was released a bit later.

[axman6]

Didn't Clang/compiler-rt have full support before GCC/libcxx (or whatever it's called) did? In my mind, and the minds of most others, this means actual full C++1 support. GCC claimed it early, but only because the compiler supported it fully, though afaict there were features which weren't supported in the runtime. Clang/compiler/rt fully support the language, and I believe they were the first to do so.

[Someone]

http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Standards.html#S...:

"For information regarding the C++11 features available in the experimental C++11 mode, see http://gcc.gnu.org/projects/cxx0x.html"*

That link shows that the compiler is feature complete, and refers (indirectly) to http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#s... for library support. That has quite a few 'missing x,y,z' or outright "N" markers.

gcc 4.8.1 is from May 31; Clang/LLVM _claimed_ full C++11 support in June (http://blog.llvm.org/2013/06/llvm-33-released.html)

Does that mean that clang passed the finish line earlier? Maybe, but it could just be that the gcc project looks harder for bugs in their own project, thus placing their finish line farther out.

Frankly, it doesn't really matter who was first. It's way more important to know whether the compilers generate correct code and if they do, that it is efficient.