C++11 and The Long-Term Viability Of GCC Questioned
phoronix.com
phoronix.com
There is a vast body of consumers who care more about maturity and stability than a few convenient front-end tricks, which the majority of C++11 ultimately amounts to. As for whether GCC is somehow "too far gone" to catch up, well that's just nonsense, the core technology has barely changed in 10 years. Things will improve when commercial needs arise and as eager PHDs hunt for final year projects.
While ancient, there is immense diversity in GCC's configurations, and AFAIK its code generator still maintains an edge over Free alternatives. Of the purported speed improvements elsewhere, anecdotal evidence from my Macbook suggests LLVM is slower at building smaller projects (predicted long ago by smart types that knew LLVM was only fast because it lacked features).
It's worth noting that GCC already supports significantly more C++11 than either MSVC11 or ICC, although this article makes no such comparison. Like the majority of articles from Phoronix, this one is blinded by the new hotness (LLVM) and a generally superficial appreciation of the subject matter.
As always, this can be a case of what's best vs what's best for my case.
Could it be ousted? Sure, if a gnu (or otherwise foss) competitor steps up and does it better (good luck..) but in that case, no problem. Could it be that the gnu/linux distributions and applications running the majority of the internet will have to rely on a proprietary compiler or die? That's just wildin' - issues aside that's nothing even any of the major corporations could really suggest.
There is a pretty compelling argument that LLVM and Clang are doing precisely that. And the "toolability" referred to in the article is a big part of that. Clang complete[1] is an example of using Clang to do things that the GNU toolchain thinks are perfectly doable with a box of regex. (Spoilers: they're so not.)
And then moved their entire OSX and iOS development community as well ?
Borderline intentional sabotage against AMD, because they can obviously do better and I don't believe they are unaware of the capabilities of AMD CPUs.
(edit: And they should probably be checking for features instead of vendor IDs anyways. It's like checking for Firefox in the user-agent and sending animated GIFs instead of WebGL if you're on Chrome)
Here's some more info: http://en.gentoo-wiki.com/wiki/Intel_C%2B%2B_Compiler#Uncrip...
It was generating bad code for anything that wasn't Intel.
MVSC is Windows only proprietary compiler and certainly hasn't had stellar C++ standard support although they are trying to rectify that with their recent 'Go native' push.
I have had no experience with IBM's XLCC compilers though, maybe someone else has?
You'd rather be loudly wrong than humbly corrected. A strange sentiment to hold.
If upgrading from one version of GCC to another is a big deal, I can only imagine how excited avionics stakeholders wouldn't be to switch compilers altogether.
It may happen eventually, but then again... it may not. Just so long as they are happy to use some GCC build from 2002 or whatever, and just so long as there's no pressing need to use something else, why should they take on the effort and expense of switching?
At the highest levels of safety, the DO-178B standard for aviations systems requires compilers to generate code in a way that has a fixed structural relationship between source and output patterns, where each pattern is independently verified, so that every output instruction is directly traceable to a source instruction. All other code generated by the compiler has to be manually verified. This eliminates the use of most of the optimization techniques found in modern compilers. Also, the emphasis on Worst-Case Execution Time (WCET) verification means that performance improvements only matter if your WCET estimates can incorporate them.
They would and they do.
I'm not sure what the second paragraph is trying to say. GCC (and Clang) optimizations can be turned off selectively or entirely altogether.
DO-178B doesn't prohibit optimizations in general.
We used different operating systems and different databases and programming languages to create a redundant system that solved the same problem or generated the same report. We would have at least three programs running with three different technologies and if the reports were all the same, the system was in good shape, but if one of the reports differed somehow we knew we had to check and fix something.
We did use SunOS/Solaris, HPUX, Linux (Slakware IIRC), DOS/Windows 3.0, Windows 95, Windows NT, etc. In some cases there were C programs using the native C compiler with whatever Unix system that was in use, and in the case of Windows or DOS we used whatever language or software was available. I worked in Clipper, DBase, Oracle PL/SQL, SQL Server, MS-Access, and sometimes even flat text files downloaded from mainframes or FTP sites on the Military network that needed converting to different databases. As a federal contractor I was limited in what I could do, for example my PC did not have a CD drive and they would not allow ODBC drivers to be installed. I did not have administrative access but instead access to a maintenance account that others shared to work with databases that was limited in many ways.
My point is you work with whatever they give you to work with, you may be limited in what you do, but you use what you have available. So yes you might be limited to GCC on a Linux system and no root access to install CLANG or LLVM.
Was this before or after Bradley Manning? (I think he used a CD-RW drive on a "secure" computer to extract the data he sent to Wikileaks.)
> account that others shared
Shared account? Really? Sounds like top-notch security in action. [/sarcasm]
> no root access to install CLANG or LLVM
You don't need root access, you can just do:
./configure --prefix=$HOME/clang
or whatever the equivalent is if clang uses a different build system.
If /home is mounted noexec, that's a real problem, but if you're doing software development, noexec would mean you couldn't run the programs you're writing either.
Of course, just because there's no technical reason you can't do something, doesn't mean there isn't a nontechnical / political reason you shouldn't. If you'd made a project change as large as using a different compiler without approval from (or at least notification to) higher up, you might have gotten in trouble.
You will find that not all federal systems are secure and run by experts. Some federal employees are not qualified for their jobs, and that is why federal contractors are hired to make up for it. For example some of our servers and systems were not behind a firewall and had public Internet IP addresses. I agree a shared account is a security risk, and when someone changed the password to the maintenance account we were locked out and had to file a form to learn the new password. In fact to do anything like install software or configure a system we had to file a form first.
Yes the federal government and chain of command requires that I file a request before I use a new software product. Even if it can be downloaded and run in the home directory, if I don't get permission for it, I am in deep trouble. So much as refreshing an IP address, if I do it myself I am in trouble, I have to call their help desk and have them refresh and renew it for me.
Switching compilers isn't that difficult, especially when they're as reliable as GCC and Clang.
I can understand those that only want permissive licensed software for components. This make sense, as otherwise the copyright license will put some requirements when distributing copies of the new work. If its proprietary components, you got to buy a license. If its copyleft components, you got to use a particular license.
But if we are talking about gplv2 vs gplv3, only a very small subset of people will ever have to care about the differences between those two licenses. It actually only comes down to two questions.
1: Are you planning to sell a product, but want to keep root access to the device after its being sold, while at the same time directly preventing giving the same access to the new owner who bought your device?
2: Are you in a patent license agreement with an other company over patents you pay for and which cover aspect of the new product?
If your answer is No and No, to those two questions, you can regard GPLv2 and GPLv3 as identical licenses. Its that simple.
I doubt this is rare inside of large corporations.
Not only for contributing, but for using as well, and with every single version change the same process must be followed.
For code contributions, GPLv2, GPLv3 and Apache license has the exact same deal in regard to patent grants. Actually, the text used in GPLv3 that cover patent grants of contributors, is word for word copied out of the Apache license. GPLv3 only added additional patent requirements for distribution of the complete work. My guess, for the exact reason of not discouraging companies to contribute code.
If the company review GPLv3 contributions, but do not review Apache licensed contributions, they have bitten the FUD apple.
If your in a situation where you want to use someones else project, and would be willing to pay per unit to distribute it to your users, what would you pick. A patent deal to get the privilege to distribute a GPLv2 program, or a supported and legal protected proprietary program? I would pick option 3, ie, write my own program or fight the patent depending on which ever is affordable. In this regard, what license the original program was in matter very little if at all.
https://wiki.freebsd.org/GPLinBase
Apple (as they would not accept GPLv3) was stuck with shipping the very old GCC 4.2.1, also Apple wanted to be able to incorporate the compiler toolchain into their proprietary solutions like XCode, something GPL obviously won't allow. Hence funding LLVM while starting work on Clang made sense for them, but again not a choice made (purely) on technological merits.
I think it's inaccurate to portray the move away from GCC as simply political with happy side effects, though avoiding the GPL3 was certainly a prime motivation. Greg Parker has stated on Apple developer mailing lists that the adoption of Clang/LLVM has allowed them to rapidly improve the Objective-C language, and that there are more Apple employees working on the language and compiler today than 10 years ago.
Mozilla switched its Mac builds from gcc 4.2 (or rather the Apple fork of it) to clang, because the cost of doing the switch was lower than the cost of avoiding all the bugs in said fork of gcc 4.2 that didn't exist in the other three compilers the codebase also had to compile with (gcc 4.4 on Linux and MSVC).
https://groups.google.com/forum/#!topic/mozilla.dev.platform...
The end result produced by gcc in some cases is more performant (looking at profiling output), however we continue to use clang because most of our code spends a LOT more time in I/O than it does in certain tight loops that GCC would optimise, and clang produces better diagnostic output, and compiles faster thus we get feedback faster and spend less time waiting for our codebase to compile.
We don't pass in any optimisations at all, especially during development. We have found a couple issues in the past whereby -O3 or even -O2 would cause GCC AND/OR clang to miscompile code. So we simply dropped all optimisations.
If switching on standard optimizations is causing "miscompiled" code, especially in both GCC and Clang, it's very likely that your code has silent bugs that are revealed by optimizations. Compilers are perfectly allowed to perform very unexpected optimizations where they detect undefined behavior.
One of the gdb gurus at Google was telling me about a bug brought to him by a fellow engineer, where both branches of an if-else had logging statements in them, and the common code after the branches had a logging statement. Only the logging statement after the if-else was logging anything. It turned out that the branch condition was the result of undefined behavior and under very specific circumstances, gcc had optimized away both sides of the if-else. The optimizer had essentially decided that the bool was never true and was never false. This wasn't a compiler bug. For implementation-defined behavior, C compiler are required to do consistent and sane things. For undefined behavior, C compilers aren't required to do consistent or sane things. Essentially, undefined behavior are the corner cases that compiler writers are explicitly allowed to ignore when performing optimizations. A classic example is int i; for(i = 1; i > 0; ++i) could legally be left alone on one line and be optimized away to while(true) a few lines later, since overflow of signed integers is undefined behavior, the compiler is allowed to perform optimizations as if overflow can't happen.
At one point we were using an older version of GCC, and an older version of clang and both would miscompile different pieces of the code with optimisations turned on. A lot of things have been fixed since then. There were a few cases where the code that was written was undefined in the standard and the compiler could do as they pleased, but there were quite a few cases where that wasn't the case. The places where it was undefined we fixed, the others we never did figure out what was going on. Newer versions of GCC/clang did the right thing, so we finally upgraded, solving a whole lot of the problems.
At this point in time it just doesn't make sense for us to compile with optimisations turned on, so why risk it?
GCC is stagnant, but the dynamic pace of development on the Clang front means that either the GCC developers will adapt, or the community will adapt GCC for them.
Yes, gcc has commercial backers, too, but I think at the moment most of them are more willing to pay for the support of additional architectures or architecture variants than for new language features (at the moment; that can change if C++11 gets more commonly used)
It's the "nice" version.
The reunification is kind of glossed over here, but what happened was the FSF fought it all the way, realized EGCS would win, and accepted it back.
GCC got concessions as part of this reunification. The concessions were that GCC would have it's own steering committee, and that we could appeal any RMS decision to the board of the FSF.
For one, there wasn't any viable competition at the time. Your options were GCC, or a commercial compiler. If you actually needed access to the source code of the compiler for any reason, GCC was your only option.
So, when it became clear that the FSF and the community wanted to take GCC in different directions, the obvious choice was to fork GCC. The fork developed far more rapidly than the original, draining developer time (and users, for that matter) from GCC mainline. Basically, at the point where the FSF anointed egcs as the new GCC, the original GCC project was already dead.
Things are a bit different nowadays.
There are already disagreements between what people wanted to do with GCC, and the FSF. Especially around the tool support the article talked about - the FSF are against reorganizing GCC so that parts can be used as a library for political reasons. They were against plugins for the same reason originally. They have been resisting any attempts to clean up or modernize the codebase (they've been doing it, but very slowly, because it takes the steering committee a long time to... erm... steer).
There's an alternative - Clang / LLVM, which is built around that kind of tool support, has less niche stuff to get in the way, cleaner, simpler codebase, no legacy stuff. A good few GCC developers have jumped behind that instead, rather than trying to work against the FSF, and Clang isn't having the kind of problems attracting new developers that GCC is.
At this point, it does look like GCC is in trouble. The problem is that there might not be anything that anyone can do about it. As with all large projects with a long history, GCC has a hell of a lot of inertia, and it would take massive effort to shift the direction of the whole project, and make the changes that need to be made, especially considering that they can't just stop and spend a couple of years refactoring (which would definitely kill GCC).
Back then the there was an obvious threat of GCC becoming little more than a backend/frontend solution for proprietary interests which could lead to the open source part eventually wither and die.
Steve Jobs when at NeXT illustrates this problem as he tried to combine NeXT's proprietary ObjC frontend with GCC's backend and sell it under the reasoning that the 'end user would do the linking', he couldn't legally do so which is how GCC ended up with ObjC support which it otherwise hadn't, atleast not then.
Nowadays open source is established and it's benefits are well proven so these choices may look overly paranoid when viewed in the open source landscape of today, but back then and for a long time in GCC's development they certainly weren't.
The fact that an open source free compiler toolchain like GCC has established itself as such a 'de facto' solution has obviously had an incredible impact on the acceptance of open source in general, not to mention that Linux, the open source BSD's, and tons of other open source projects (and likely lots of proprietary projects aswell) would never have gotten anywhere near where they are today had it not been for the existance of GCC, a top-notch compiler toolchain free of charge and free to distribute.
It's possible to fork the code, but it's more difficult to fork the community. It's the problem that the BDFL have to solve to survive.
Most Phds I know in CS, have done work not directly related to their main research point. Usually in the 6 months before the deadline some way was found to relate the work with the thesis and it got written in those remaining months.
Really great point. I don't understand why this article focused on C++11 of all things. Until recently, gcc had much more complete C++11 support than Clang. Now, it seems they're about on par (if feature tables are any guide[1]). In fact, a couple years ago I was about to switch to Clang but when I started using C++0x I had to stick with gcc because Clang's support just wasn't there yet.
Also, LLVM's C++ Standard Library (libc++) is still pretty immature on Linux, so even if you use Clang for C++11 you're probably going to end up using gcc's standard C++ library anyways!
So yeah, this article is pretty sensationalist.
[1] http://gcc.gnu.org/projects/cxx0x.html and http://clang.llvm.org/cxx_status.html
Never believe anything you read there without independent verification, and even with verification, be suspicious....
The only thing that could stop it is if it's no longer an FSF-run project, or the steering committee actually started replacing older members with people still working on GCC, or something else drastic. This would enable folks to do things that currently take a lot of energy to fight about. It may also have to compromise some core values in order to serve the most users.
Yes, LLVM currently lacks optimizations GCC has. But LLVM will do the same thing GCC did to commercial compilers when we started the tree-ssa project, and cherry pick the high end of research, and implement it (it has already started).
As long as GCC stays on the path it is, it will die. It will be a long time, because it has a lot of users. LLVM is friendlier to developers, researchers, and users. GCC can't win any fight as long as that is true.
FWIW: I also don't think most GCC developers harbor any illusions about the above. I think RMS may, or may not be involved enough to care, but nobody seriously involved in GCC thinks that GCC is in "a-ok great shape no problems"
The other possibility, of course, is that LLVM will end up on the same path GCC does, and thus, they will be on the same terms again. I doubt this, since Chris Lattner saw what happened when he tried to merge GCC and LLVM, and despite his flaws, is much more savvy about politics and community policies than GCC is.
A lot of discussion of this proposal happened offline. The end result was basically that Chris withdrew it (though not formally), though GCC would have rejected it anyway.
GCC was mostly unwilling to throw away what they had (nobody was really up for rewriting everything again), and Chris realized it would be a disaster to his community. Imagine trying to unify the stereotypes of the ruby and python communities, or something like that (i use this only as an example of the level of difference in ideologies between the GCC and LLVM communities)
In practice, this was probably the right social outcome given the set of developers/people involved on both sides. From a pure technical perspective, it's much harder to say.
Clang is designed to be highly compatible with GCC-dependent projects, from extensions to command-line arguments. What's to stop them from just switching to Clang if GCC's complexity and lack of documentation prevent it from remaining competitive?
gcc is dead. It served us very well, but it is time to move on.
It seems like the open source community is working as it should here: someone designed a better mousetrap, and the world beat a path to his door. This is the way things should be, and the net result is going to be better open source software for everyone. Nobody wants to keep COBOL alive or CVS, so let's not be overly sentimental about gcc.
A backwards compatibility argument (whatever it may be) doesn't make sense here, as Clang has been designed to be backwards compatible with GCC-based projects.
But I was pretty surprised by the attitude that surfaced very early in the linked thread on the GCC list, too. Outwardly hostile, as if to say, "well damn, you losers sure better catch up with LLVM right this instant, otherwise you're making lame excuses". I don't have any involvement in either project (other than the fact that I've used and appreciated both compilers), but this strikes me to fundamentally misunderstand open source. Does LLVM have to fail for GCC to succeed?
And a lot of companies will still go with the latter. GCC is fine, and won't "die". The systemic problem in LLVM/Clang vs GCC is that the former is modular and has an intermediary language that makes new compiled languages much easier to implement a compiler for. The resut is that if you were to write a new compiler, LLVM is so far and away the best choice it isn't even a content. So it has momentum GCC doesn't, and that momentum means it will see much more active development.
The forced transition to GPL v3 isn't helping. OS X and Free SD are both largely transitioned to LLVM. Linux is a holdout, but how long will it be able to prop up gcc on its own?
It's muddy mainly because GNU coding standards and portability rules prevented people from doing things right when they had the time to do it.
As for Linux relying on GCC, Linux relies on lots of GCC compiler extensions, many extensions which exists as a direct result of requests from kernel developers.
You need to patch both Linux and Clang/LLVM to be able to even compile Linux with Clang/LLVM, and the result is unstable, so it's not as if Linux is a 'holdout' by any measure.
Example overview: http://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from-...
1. DUChain was designed to support multiple languages (since KDevelop does). E.g. there is work going on now to offer first-class JavaScript support in KDevelop, which libclang wouldn't help with.
2. No one has done the work to verify API/ABI compatibility guarantees, porting libclang into DUChain, etc.
There's interest though:
https://bugs.kde.org/show_bug.cgi?id=253650 https://bugs.kde.org/show_bug.cgi?id=172622
Wasn't this essentially what the egcs project did? It's possible that GCC might need another round of this; could doing that provide a potential avenue out of the current troubles?
So yes, I'd say you are quite correct in your assessment.
On the other hand, the stories also all seem true. There really is a serious problem with being attached to the FSF being a liability, and RMS really has held GCC back, and is (in my opinion) the main reason clang/llvm has been able to move ahead in some areas (in particular tool support), where for years RMS explicitly rejected any patch which would make gcc "tool-friendly".
Two of the top technology companies (if not THE top two), Apple and Google, are backing Clang/LLVM development for their technologies after having been dependent on GCC for a number of years. There must be a reason for that worth discussing.
Most of the code didn't need changes, except where it handled strings (or the char *string1 type string) because somehow gets() caused a segment fault and when I switched to scanf() it worked without crashing. When I used the math.h library and the sqrt() function I had to use the -lm switch on the compiler to get it to work.
I rewrote them in C++ using the G++ compiler and found that the std::string works better than the old C string, and that the cin and cout commands work better than gets and scanf.
I really don't see much of a problem unless you are converting Pre-ANSI C code to the current standard or something. I think that the scope changed, but back in 1987 we were taught to keep variable names used in functions inside of functions, etc to keep the scope the same and don't try to access something out of scope. I guess that is why my programs converted so easily? They also didn't need a lot of resources or libraries and were simple programs written for the command line for DOS using Turbo C.
Should I use CLANG or LLVM instead? How about Visual C++ or Borland C++? Am I doing wrong trying to learn GCC and G++ or should I try learning under a different C++ compiler?
How long until RMS lets us drop the GNU/ part in what he calls Linux?
Here's a pretty good talk about the philosophical motivations behind Clang and the current work being done on it:
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
And please don't link to that RMS email as "evidence"; RMS has about as much control over GNU projects' technical details as Charles Manson does over the music industry.
The claim I've seen repeatedly is that this is precisely because they must now compete with Clang/etc.
Previously GCC's primary competitor was ICC, and they were compared based on the quality of their output. Now GCC's primary competitor is Clang, and they compete on how user-friendly their interface is. Modularization is a user interface improvement, just like better error messages or more comprehensive warnings.
Because Clang happened.
http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html
In this case, Stallman not only indicated that the code should not be accepted, but even requested that the code that had already been published be retracted. He felt that Java bytecodes were sufficiently high-level that they could be used as an intermediate language, allowing closed-source backends to be indirectly connected to gcc's frontends.
FWIW, here again, it isn't clear whether going to RMS was even the right path; it could be that addressing the gcc mailing list in the first place would have caused a different discussion. In fact, even once posted to the gcc mailing list, the response was actually largely positive, although now somewhat colored into a discussion of the e-mail thread, and not the patch; I am not certain (but would love to know) why this patch then continued to not happen.
I've always thought RMS was a little off, but I just chalked that up to the typical eccentricities of genius. This isn't just eccentric though: suppressing code in the name of freedom is just plain evil. I'm not sure how anyone can take RMS, and by extension the FSF that he controls, seriously anymore.
Well, if it makes you feel any better (or, alternatively, worse, I guess, in which case I apologize :(), I do (to be explicit: take RMS seriously). I didn't in 2002, which is part of why I can pull these examples do quickly: I considered Stallman an extremist and I found his definition of "freedom" confusing. I often had to cite these various email exchanges.
However, over the course of the last ten years of being a developer of open-source tools, I've entirely reversed my opinion. I have found myself more and more frustrated with the attitudes people take towards open source contributors, and I have seen the licenses on my open work become more and more defensive against these abuses (sometimes even using AGPL).
In fact, this whole Apple/Clang debacle was one of the things that pushed me over: this only became "a thing" when gcc moved to GPL3, and seems mostly about Apple wanting to maintain and expand a fully-closed ecosystem, not about technological advantages. In my opinion, the "great GPL purge" of Mac OS X is going to lead to some dire consequences on computing.
The recent Android NDK r8c (November 2012) includes clang 3.1 as an experimental alternative to gcc 4.6. This suggests that it may become the default in future versions of the Android NDK. If Google, like Apple, drops gcc for clang, which major commercial entities will be helping to fund gcc development?
The fact that RMS would tell someone to take a GPLed extension to GPLed code off their website, and never mention they exist, seems fundamentally against the principles of free software. How was this not a controversy of the highest order at the time? I'm amazed I missed it.
That said, I agree that this example sucked: the argument wasn't even that strong, party because I get the impression that Stallman doesn't really "get" Java (based not just on this example, but from other situations where Java comes up; it just seems like he never looked at it very closely to see what it really wasn't actually capable of: he seems to give it much more credit than it is due). The comments on the mailing list seemed to defeat his argument, which is why I continue to be confused that the discussion didn't continue.
As for why more people don't know about it, I don't know: it was a somewhat big deal on a bunch of mailing lists (again: it hit freebsd-advocacy and turned into a major event, somewhat bolstered by the GCC Introspector guy I mentioned elsewhere in this thread getting involved an sharing his stories as well). I can only imagine that not enough people care about mailing list history. :(
You might argue that compliance with copyright law is a "political reason", but I think you'd find that to be a very difficult position to defend.
By your own words, you've been working for three years on trying to get information out of GCC for use in other tools. Even if you have no intent of trying to attach proprietary back ends to GCC, you are working very hard to enable others to do so.
...
> I think the GCC list has to ask itself how long are we going to wait before addressing the issues at hand, and not just ignoring the problem to death.
As long as possible, because as long as there isn't a really clean way to attach proprietary front ends and back ends, people who are on the fence about going proprietary or submitting their code back will choose the latter.
-- Joe Buck, http://gcc.gnu.org/ml/gcc/2002-02/msg01823.html
(To note: James Michael Dupont, the person doing the work on Introspector, himself was perfectly fine with the licensing even being quite explicit that things attached to his XML data feeds would have to be themselves GPL. This was clarified, and people seemed to understand; however, his work was still being explicitly rejected as it could lead to proprietary backends.)
You still think that I think you're a bad guy. I don't. Long-term, GCC is going to have to open up the interfaces. Our current policy is that we don't accept patches that do this, but we can't prevent others from doing it.
-- Joe Buck, http://gcc.gnu.org/ml/gcc/2002-06/msg01392.html
(Honestly, I'm not even certain this is the wrong attitude for the FSF to take, although it certainly is a futile one: you can always build in your own mechanisms to do this, or hell, use one of the new alternatives. It really seems somewhat important that the FSF has been around as long as they have been taking a stance that they refuse to water down; yes, it would be better if we all could work together without this kind of inanity, but the world isn't perfect.)
That gcc, like most other C++ compilers, does not support it, means little.
Last time I checked C++11 has been an ISO standard since last August, with MS and Clang ramping up their support for it.
The answer is that languages are hugely important. C++11 is an entirely huge language and having a standards and feature compliant compiler is critical to being productive in the language.
The notion that C++11 doesn't exist is novel given that I'm using it regularly on both platforms that I consider relevant.