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

Rust and GCC, two different ways

Posted Oct 4, 2021 22:18 UTC (Mon) by Trelane (guest, #56877)
In reply to: Rust and GCC, two different ways by randomguy3
Parent article: Rust and GCC, two different ways

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

to post comments

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.