Rust and GCC, two different ways [LWN.net]

Rust and GCC, two different ways

Posted Oct 4, 2021 20:12 UTC (Mon) by tialaramex (subscriber, #21167)
Parent article: Rust and GCC, two different ways

> Developers working in languages like C or C++ have access to two competing compilers

Three. There are exactly three compilers for C++ in 2021. GCC's G++, LLVM's Clang, and the Microsoft Visual C++ compiler. Somewhere in the modern era the pace of development of C++ out-stripped the capacity of third party compiler vendors to keep up, while the price people were willing to pay for a compiler dropped, and they stopped bothering.

Now of course here on LWN we care mostly about Linux, but it's worth reflecting on the fact that "diversity" is often portrayed as a strength of C++ and that diversity consists only of three implementations with fairly incestuous relationships. For example the entire MSVC standard library source is published just like its equivalents from GNU and LLVM, and you will see primary authors of two standard libraries attending talks by authors of the other one on this or that interesting trick they exploited or corner case they wrestled with - after all they're by definition the most interested parties.

If we get two similarly "competing" compilers for Rust that's almost the same diversity.

to post comments

Rust and GCC, two different ways

Posted Oct 4, 2021 21:28 UTC (Mon) by randomguy3 (subscriber, #71063) [Link] (10 responses)

If we're counting proprietary compilers, then ICC (Intel's compiler) is still alive and kicking, for those willing to shell out money for it (and many companies are, as it apparently is better at certain classes of optimisations than other compilers when you're compiling for an Intel - or Intel-compatible - target).

I'm not sure that Intel maintain their own standard library, though - I think they may borrow it from another installed compiler.

Rust and GCC, two different ways

Posted Oct 4, 2021 22:18 UTC (Mon) by Trelane (guest, #56877) [Link] (8 responses)

There are indeed a number of c++ compilers. https://www.stroustrup.com/compilers.html

Rust and GCC, two different ways

Posted Oct 5, 2021 0:17 UTC (Tue) by wahern (subscriber, #37304) [Link] (2 responses)

That page is a little dated. Intel C++ recently switched to clang and LLVM (as mentioned elsethread), following IBM's XL C/C++ recent move to a clang frontend (see https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=n...).

That leaves Microsoft Visual C++ and Solaris Studio as historically popular compilers using (by default) neither clang nor LLVM. I'm not sure if Visual C++ still uses the Edison Design Group (EDG) frontend, but many niche proprietary parsers and compilers do. AFAIU, for bleeding-edge C++ support the traditional big players were EDG, GCC, and (relatively recently) clang.

Rust and GCC, two different ways

Posted Oct 5, 2021 5:33 UTC (Tue) by joib (subscriber, #8541) [Link]

Seems for version 17 they have rebranded as "Open XL": https://www.ibm.com/products/open-xl-cpp-aix-compiler-power

Rust and GCC, two different ways

Posted Oct 7, 2021 20:05 UTC (Thu) by ms_43 (subscriber, #99293) [Link]

The Visual C++ *compiler* never used the Edison Design Group (EDG) frontend, while the Visual C++ *IDE* did.

https://devblogs.microsoft.com/cppblog/rebuilding-intelli...

As regards Solaris Studio, I am happy that its so-called C++ compiler is but a distant memory for me now.

Rust and GCC, two different ways

Posted Oct 5, 2021 0:36 UTC (Tue) by roc (subscriber, #30627) [Link] (4 responses)

That page is somewhat misleading, because the same underlying compiler backends appear multiple times, others are far behind the latest C++ standards, others have completely disappeared, and others are listed twice as "free" and "nonfree" editions.

Apple C++. Xcode. It also comes with OS X on the developer tools CD.
Clang C++. A relatively very active development associated with the analysis and code generation framework, LLVM.

These are based on clang++.

Intel C++ and many supporting tool
Intel C++ for Windows, Linux, and some embedded systems.
IBM C++ for IBM power, System Z, Bluegene, and Cell.
Embarcadero C++

These are transitioning to clang++.

Bloodshed Dev-C++. A GCC-based (Mingw) IDE.
GNU CC source
Cygwin (GNU C++)
MINGW - "Minimalist GNU for Windows". Another GCC version for Windows including a free (non-GPL) w32api.

These are all based on g++

Microsoft Visual C++.
Microsoft C++

These are Microsoft's own compiler.

Mentor Graphics - Lite edition. Sourcery CodeBench.
Mentor Graphics Sourcery CodeBench An extensive "Workbench" for many embedded systems platforms.

Apparently is "either gcc or llvm"???
https://www.plm.automation.siemens.com/global/en/products...

Oracle C++.

Last stable release in 2017.

Edison Design Group C++ Front End - used by many C++ compiler suppliers

Only a front end, not a compiler.

Green Hills C++ for many embedded systems platforms

Seems to be its own compiler! only supports up to C++17.

The Portland Group C++ (parallelization and GPUs)

Bought by NVidia, but appears to be a genuine C++17 compiler.

WindRiver's Diab C++ used in many embedded systems.

Uses LLVM backend, not clear whether the frontend is clang++ or something else.

HP C++

Seems to have disappeared long ago.

Paradigm C++, for x86 embedded systems

Very obscure, practically no information online.

So looks like 5-7 genuine, independent, somewhat up to date C++ compilers on Stroustrup's list.

Rust and GCC, two different ways

Posted Oct 5, 2021 1:12 UTC (Tue) by willy (subscriber, #9762) [Link] (3 responses)

So, I'm confused. I think it's fine to dismiss/merge multiple compilers based on being substantially the same. But I'm not clear on what "counts" as being "a C++ compiler". Is it the front end, the back end or the IR?

I'd argue the front end (everything from calling read() on the .cpp file to generating IR) is the important bit for "being a C++ compiler". IR to assembly/binary is code generation and essentially language independent.

So if a compiler uses g++ as its front end and does magic stuff afterwards, fine, let's dismiss it, but there are some compilers in this list being lumped together because they use the same back end, and I think that's bad logic. eg EDG should count, even though it doesn't do code gen.

Rust and GCC, two different ways

Posted Oct 5, 2021 2:13 UTC (Tue) by roc (subscriber, #30627) [Link] (2 responses)

That's fair. That possible adds Embarcadero C++ and EDG to the list of "C++ compilers". But I don't know how many compilers on that list use EDG.

Another issue is that some of those compilers are hardly used. The mere existence of a compiler that hardly anyone uses or even tests against is not really significant.

Rust and GCC, two different ways

Posted Oct 5, 2021 5:26 UTC (Tue) by joib (subscriber, #8541) [Link]

IIRC PGI and pre-LLVM Intel use EDG?

That being said, it seems nowadays there's not that much interest in proprietary language extensions, and thus the focus on these proprietary LLVM forks seem to be in tuning (including new optimization passes?) for the particular vendor's CPU's. And maybe some improved runtime libraries. So in that sense it makes sense for the vendors to collaborate on an open source frontend (clang(++)) , as the secret proprietary juice is elsewhere.

Rust and GCC, two different ways

Posted Oct 5, 2021 10:25 UTC (Tue) by andrewsh (subscriber, #71043) [Link]

Apparently Embarcadero switched to Clang some time ago.

Rust and GCC, two different ways

Posted Oct 4, 2021 22:51 UTC (Mon) by Gaelan (guest, #145108) [Link]

ICC appears to be getting replaced with a proprietary LLVM fork: https://software.intel.com/content/www/us/en/develop/blog...

Rust and GCC, two different ways

Posted Oct 5, 2021 13:50 UTC (Tue) by Paf (subscriber, #91811) [Link]

This is a pretty standard/natural thing in economic systems over a long time - consolidation. It’s not ideal, but as the depth of investment required to compete rises (and it almost always does for a technology as it grows), the market supports fewer competitors. It’s just… something that happens.

Some things are lost, some gained, but the fact is the world is showing it doesn’t see the cost benefit equation of many competing entirely distinct compilers working out. It’s too hard to offer much advantage, especially vs quite good free options.

Successful open source is sometimes really good at driving consolidation, for obvious reasons. Since “free” makes the cost benefit equation for competing vendors a lot harder.

It just … is. It’s not a C++ problem specifically, I think.

Rust and GCC, two different ways

Posted Oct 11, 2021 18:52 UTC (Mon) by dpc (guest, #74012) [Link] (2 responses)

Multiple compilers (and the official spec/standard that comes along with it) is just a hindrance. It made sense in the era of paid, propriety programming languages, OSes and their vendors, etc. When the language *is* an open source, very liberally licensed, free, portable implementation, there is really no big need to have any additional implementations. What we need is more features: more supported platforms, etc. It might be achieved by a different compiler implementation (framework) or reusing parts of it, sure And there are some big benefits of multiple compiler implementation, like trusted bootstrapping. But in itself it's a cost, not a feature.

Rust and GCC, two different ways

Posted Oct 18, 2021 4:17 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

> When the language *is* an open source, very liberally licensed, free, portable implementation, there is really no big need to have any additional implementations.

Anyone who tried to use such an open spec on Microsoft platforms that claimed to support it between at least 2000-2010 would probably disagree with that point. C, HTML, Java, POSIX...

Rust and GCC, two different ways

Posted Oct 18, 2021 8:35 UTC (Mon) by farnz (subscriber, #17727) [Link]

Those are additional implementations of the standard that weren't liberally licenced, free or portable. Which kinda emphasises dpc's point - multiple specification-compliant implementations is only beneficial if all implementations are of high quality.

Rust and GCC, two different ways

Posted Oct 12, 2021 16:00 UTC (Tue) by Aldrichwright (guest, #154721) [Link] (3 responses)

"exactly three compilers for C++ in 2021"

Funny, can I can think of others. There's the Intel C++ compiler for instance as well as the IBM XLC++ for the mianframe. Let's not forget Embarcadero's C++ compiler-C++ builder (derived from Bordand's C++).

So, there may be 3 compilers in common use for macOS, Linux and windows but:

1. There are a lot more platforms than those three (unix, vms.... which I believe still runs somewhere, etc).
2. There are other C++ compilers that run on those three platforms, of which Intel and Embarcadero are two.

Rust and GCC, two different ways

Posted Oct 12, 2021 16:11 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

> 2. There are other C++ compilers that run on those three platforms, of which Intel and Embarcadero are two.

These both are Clang variants these days apparently. Not fully independent implementations anymore.

Rust and GCC, two different ways

Posted Nov 12, 2021 12:09 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (1 responses)

IBM's XLC++ had _partial_ support for C++ 11. The last version of C++ they claim _full_ support for is C++ 03. If you're excited about anything less than 18 years old in C++ maybe it works in XLC++ but probably it doesn't. Being pragmatic, IBM abandoned XLC++ and shipped Clang instead.

Intel and Embarcadero likewise shipped Clang. Because again, they couldn't keep up. You put your team to work delivering C++ 11 and by the time they're shipping alpha previews the committee finalises C++ 14. So you ask customers, do you want us to focus all our effort on C++ 14 or should we regroup and just ship LLVM's perfectly good C++ compiler but with all the nice stuff you like? No surprises what the customers say.

I didn't claim that there had never been this rich tapestry of different C++ compilers, I wrote only about the status today, in 2021, there are exactly three C++ compilers.

Rust and GCC, two different ways

Posted Nov 12, 2021 13:17 UTC (Fri) by pizza (subscriber, #46) [Link]

> Intel and Embarcadero likewise shipped Clang. Because again, they couldn't keep up.

This was true for Arm too; With ARMCC 6, they moved to Clang, extending it to maintain frontend/cmdline compatibility with the older stuff. But ARMCC, as shipped, remains as proprietary as ever.

(While Arm contributes a lot to upstream GCC and LLVM, what landed upstream tended to lag significantly from what they shipped in ARMCC. Granted, that policy could have changed in the three years since I worked there...)