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

By Jonathan Corbet
October 4, 2021

Developers working in languages like C or C++ have access to two competing compilers — GCC and LLVM — either of which can usually get the job done. Rust developers, though, are currently limited to the LLVM-based rustc compiler. While rustc works well, there are legitimate reasons for developers to wish for an alternative. As it turns out, there are two different ways to compile Rust using GCC under development, though neither is ready at the moment. Developers of both approaches came to the 2021 Linux Plumbers Conference to present the status of their work.

rustc_codegen_gcc

First up was Antoni Boucher to talk about the rustc_codegen_gcc project. The rustc compiler, he started, is based on LLVM; among other things, that means that it does not support all of the architectures that GCC supports. ~~What LLVM does have~~ Rustc does have, though, an API that allows plugging in an alternative code generator. This API can be used to plug in the GCC code-generation machinery via libgccjit. That is the approach taken by rustc_codegen_gcc.

Why would this be a useful thing to do? Boucher said that the Rust language is increasing in popularity, but it needs support for more architectures than LLVM can provide. The Rust for Linux work, in particular, is highlighting this issue, but there are a lot of other users out there too. Developers of embedded systems would benefit from better architecture support, as would the Firefox browser.

A number of Rust features are supported by rustc_codegen_gcc now, including basic and aggregate types, variables, functions, atomics, thread-local storage, inline assembly, numerous intrinsics, and more. The compiler has support in the Compiler Explorer. The libcore tests pass, as do most of the user-interface tests. As an experiment, this compiler has been used to build Rust code for the m68k architecture; this work is still in an early stage, Boucher said, but it shows that it is indeed possible to build Rust programs for platforms that LLVM does not support.

There are still some problems to solve. A number of attributes still need support, as does generation of debug information. The quality of the generated code is not always the best. More work must be done to support new architectures. Link-time optimization is not yet supported, and so on. This work has also required a set of changes to libgccjit, most of which are still in review.

There are some other issues too, including the need to use a patched version of GCC until all of the changes have been merged upstream. Even then, there will be a need to backport those patches to allow the use of older GCC versions, which is important to be able to compile the kernel.

Even so, this project seems reasonably well advanced. Boucher noted that there was an active pull request to add rustc_codegen_gcc to the rustc compiler, but that's no longer true; that merge was done on September 29.

Native GCC

Philip Herron then took over to talk about the native GCC front end for Rust, known as gccrs. Rather than being a hybrid of LLVM and GCC, this compiler is a full implementation of the Rust language in the GNU toolchain. This work is written in C++ (easier to bootstrap, he said) and is intended to become a part of mainline GCC. It uses the existing binutils, and reuses the official Rust libraries (such as libcore, libstd, and libproc).

Once again, the speaker raised the question of "why?". He likes big projects, he said, so this one looked attractive. It makes for an interesting contrast with how the problems are solved in LLVM, and is a good opportunity to see how GCC handles a modern, high-level language. Once the work is done, it will be useful to compare the results in terms of code size, register allocation, and energy efficiency.

There are a lot of benefits that come from having an independent implementation of Rust, he said. Tight integration with GCC will be useful for a number of projects, which will be able to benefit from GCC plugins as well. A GCC-based Rust compiler will make it easier to bootstrap rustc on new platforms. Support for link-time optimization, which tends not to work well in mixed-compiler situations, should be improved. And, of course, GCC brings support for more target architectures.

Work toward Rust support in GCC got started back in 2014, Herron said, but then it stalled out; the language was evolving too fast for the GCC developers to keep up with it. This effort was then restarted in 2019; the recent interest in Rust for the kernel is helping to drive this project. Various companies, including Open Source Security and Embecosm, are supporting development of the GCC-base Rust compiler. There is a detailed plan in place for a "minimum viable product" compiler to be released by the end of 2022.

Thus far, working support exists for core data structures and most control flow, though some of the control-flow work is still in progress. Generics and trait resolution work. Future work includes macros, imports, unstable features, and intrinsics. Amusingly, the current compiler can build "hello world", but it requires using unsafe code; the lack of macros means that println!() is unavailable and the C printf() function must be called instead.

Work planned for further in the future includes the borrow checker, which will be done in cooperation with the Polonius project. Incremental compilation is on the list, as is backporting the front-end to older GCC versions. Longer term, it is hoped that this work will help to drive Rust compiler compatibility testing in general.

The video of these talks is available on YouTube.

Index entries for this article
Conference	Linux Plumbers Conference/2021

Rust and GCC, two different ways

Posted Oct 4, 2021 16:17 UTC (Mon) by TheGopher (subscriber, #59256) [Link] (4 responses)

I feel I’m often missing a critical discussion of LLVM and the risk of binary only distribution; where the compiler source is not available and architecture specific patches are unavailable to developers. I consider this a driving concern when it comes to requiring gcc support for rust before considering it for general use.

Rust and GCC, two different ways

Posted Oct 4, 2021 19:30 UTC (Mon) by josh (subscriber, #17465) [Link] (3 responses)

While it's theoretically possible for some architecture vendor or third party to ship a proprietary LLVM, and to ship a proprietary rustc based on that LLVM, rustc will never have official support for any target that requires a proprietary backend, so such a target would always be a permanent fork. (Source: I wrote rustc's policy for accepting new targets.)

Adding gcc support for Rust will not prevent or in any way affect the possibility of proprietary forks; those forks would just not use GCC.

Rust and GCC, two different ways

Posted Oct 4, 2021 20:41 UTC (Mon) by TheGopher (subscriber, #59256) [Link] (2 responses)

From what I've heard (but please correct me if I'm wrong) Apple already ships an LLVM with proprietary extensions/patches, though I don't know to what degree the patches are architecture specific.

I personally think the best strategy for maintaining a world of free compilers is to ensure we focus on GCC whenever possible, though not excluding LLVM as the competition is healthy.

Rust and GCC, two different ways

Posted Oct 4, 2021 21:25 UTC (Mon) by josh (subscriber, #17465) [Link] (1 responses)

> From what I've heard (but please correct me if I'm wrong) Apple already ships an LLVM with proprietary extensions/patches, though I don't know to what degree the patches are architecture specific.

Apple *appears* to ship LLVM source code, and maintain a public repository. Their patches aren't upstream, but it doesn't look like they're proprietary, unless they're adding further patches atop the public sources before shipping the version in the xcode SDK.

The issue with Apple appears to be more that their build-and-sign toolchain and requirements are based on their "bitcode" format which uses a specific version of LLVM, and using a newer toolchain produces things Apple's infrastructure won't accept.

> I personally think the best strategy for maintaining a world of free compilers is to ensure we focus on GCC whenever possible, though not excluding LLVM as the competition is healthy.

LLVM exists. You can't prevent people from building proprietary compilers atop it; the existence of GCC doesn't prevent that, only the non-existence of competing permissively licensed compilers would prevent that, and that isn't going to happen.

We can't prevent the existence of proprietary compilers; all we can do is reject them when they arise, and ensure that everything upstream is Open Source.

Rust and GCC, two different ways

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

> Apple *appears* to ship LLVM source code, and maintain a public repository. Their patches aren't upstream, but it doesn't look like they're proprietary, unless they're adding further patches atop the public sources before shipping the version in the xcode SDK.

I haven't checked, but from what I've heard they haven't published things like the pipeline description tables for their ARM chips, nor support for the matrix instructions in the M1.

Rust and GCC, two different ways

Posted Oct 4, 2021 17:03 UTC (Mon) by eru (subscriber, #2753) [Link] (15 responses)

A benefit not mentioned is that a truly independent reimplementation helps expose ambiguities in the definition of the language, and ensures the future of the language is not tied to just one implementation project, a consideration if you plan on using it in a long-lived software project.

Rust and GCC, two different ways

Posted Oct 6, 2021 7:37 UTC (Wed) by marcH (subscriber, #57642) [Link] (10 responses)

Useful but I guess nowhere near as useful as using different compilers for C which is full of undefined and implementation defined behaviors.

Rust and GCC, two different ways

Posted Oct 9, 2021 4:52 UTC (Sat) by ncm (guest, #165) [Link] (9 responses)

You don't learn how many unspecified and ill-specified details your language spec really implies until after somebody attempts an independent compiler for it. So, we just don't know that yet.

Rust and GCC, two different ways

Posted Oct 9, 2021 9:21 UTC (Sat) by marcH (subscriber, #57642) [Link] (8 responses)

We already know that the people who designed Rust carefully avoided all the C ones they already knew about.

Also, you generally don't need multiple compilers to notice _undefined_ behaviors, A single, widely used compiler is often enough to notice that the same causes don't always produce the same effects.

Rust and GCC, two different ways

Posted Oct 11, 2021 6:46 UTC (Mon) by eru (subscriber, #2753) [Link] (7 responses)

Undefined behaviour does not always mean "random" behaviour. The same compiler is likely to do some things in the same way, regardless of target, even though your language definition might say the result is undefined, or fails to define it. For example, suppose the spec of the language with just one implementation does not say in which order function parameters are evaluated. So it is is undefined, although not explicitly. But as it happens, the compiler always evaluates them left-to-right, due to the decisions of its implementer. Lots of code is then written that works fine with this compiler.

Then along comes another, independent implementation, whose author has seen it useful to sometimes use another evaluation order. It is 100% certain that some of the code that ran with the original compiler fails with the new because of this, even though both follow the spec.

Rust and GCC, two different ways

Posted Oct 11, 2021 8:15 UTC (Mon) by marcH (subscriber, #57642) [Link]

> But as it happens, the compiler always evaluates them left-to-right, due to the decisions of its implementer

Except re-ordering stuff when allowed is an optimization favorite.

I totally get your point but I suspect your example is not great and that "good" examples are fairly rare.

Rust and GCC, two different ways

Posted Oct 11, 2021 10:08 UTC (Mon) by Wol (subscriber, #4433) [Link] (5 responses)

Which is why "undefined behaviour" should NOT be a thing. It's fine for the spec to delegate the definition elsewhere, it's not fine for the spec to allow the compiler writer to do any random thing.

For example, is the size of a byte defined? It wasn't always 8 bits. The spec should be "the most convenient size for the processor to store a Western character. A minimum of 6 so the Roman Alphabet and numbers fit, a maximum of 11 so no two compilers can argue how many bits in a byte". Obviously, modern x86 architecture that's 8 bits. ICL I believe was 6. Some other architectures were 9 iirc. But the point is, you can then pretty much guarantee any compiler on a specific hardware is going to agree.

Or you offload the default decision onto the compiler - "the compiler must implement any sane understanding consistently". No guarantees that different compilers do the same thing, but it's a breach of the spec for compilers to change their implementation without warning.

The quicker C (and C++?) ditch the concept of "undefined behaviour" - even if they just replace it with "defined elsewhere" - the better.

Cheers,
Wol

Rust and GCC, two different ways

Posted Oct 11, 2021 12:15 UTC (Mon) by farnz (subscriber, #17727) [Link] (4 responses)

I disagree with you on ditching UB as a concept; UB exists in hardware, too, and ignoring that is a road to extreme pain. For example, JEDEC DDR says that reading a DRAM bit cell returns a 1 or a 0, and that the value you read will be the value most recently written to that cell. But it says nothing about what happens if you read the cell more than once before it's written, or what the cell contains on power on.

Many CPUs in the past did not define what happens if you execute an undefined instruction - e.g. instruction DD on a Motorola 6800. If you do manage to execute such an instruction, you literally don't know what the system will do. While modern CPUs "shouldn't" have similar instructions, I suspect that there are errata for some CPUs that mean that they do.

Similarly, data races between two harts are genuinely nondeterministic from the program's point of view. The exact winner of a data race if two harts try to write to the same bit cell on the same clock cycle depends on environmental conditions that influence the winner of the arbitration protocol.

Given that you have to handle UB somehow, you might as well make it exist in the language, and use it to pass on the optimizer's assumptions about meaning. Rust, for example has a reasonably tight list of things that are UB (6 items in the list, and you have to use the unsafe keyword to access features of Rust that can result in UB). There's more to go to fully define that list (notably a complete aliasing model), but it's a better place than C-style UB, which is scattered and complex.

Rust and GCC, two different ways

Posted Oct 11, 2021 15:34 UTC (Mon) by Wol (subscriber, #4433) [Link] (3 responses)

Yep. But at least with that, C can specify "what the hardware does", which is most definitely NOT undefined as far as C is concerned.

If the hardware behaviour is undefined, that's not C's problem ... it can point out (or not, as the case may be) that what the hardware does may be random.

In your case, there's also the option of saying "The hardware behaviour is undefined, it's down to the compiler how to handle it".

So basically, I'm not saying the concept of UB should be ditched entirely - at the end of the day life is random - but the language CAN and SHOULD specify what happens at the language level (after all, it's maths, it can and should specify deterministic behaviour AT THE LANGUAGE LEVEL). If the language punts it and says "we can't guarantee what the hardware will do", then that's fine. After all, "whatever the hardware does" is deterministic to a point ...

Cheers,
Wol

Rust and GCC, two different ways

Posted Oct 11, 2021 16:34 UTC (Mon) by ssokolow (guest, #94568) [Link] (1 responses)

Based on my understanding of the terms, you two are talking about "implementation-defined behaviour".

"Undefined behaviour" is used in the mathematical sense of "undefined". It's like taking the result of dividing by zero.

As such, undefined behaviour is stuff where the compiler optimizers are allowed to transform their input based on the assumption that it can never happen.

See, for example, Why undefined behavior may call a never-called function and How undefined signed overflow enables optimizations in GCC by Krister Walfridsson.

I have a bunch of links to other resources in this reddit comment if you want more.

Rust and GCC, two different ways

Posted Oct 11, 2021 16:44 UTC (Mon) by farnz (subscriber, #17727) [Link]

Specifically, Wol is talking about making all UB implementation defined; however, there is UB that is not implementation definable other than as UB in the implementation.

Rust and GCC, two different ways

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

When you say "what the hardware does", what hardware (and OS - some things will trap into error handlers and be turned into something by the OS) do you mean? If you mean "any hardware and platform you can reasonably run C code on", then you're advocating for the existing position, where the things that are UB in the C standard are also UB on some real hardware - e.g. division by integer zero is UB on some CPUs that run C code).

At the other extreme, you can say that it's only UB if it's also UB on the specific platform the code is running on - but note that in the past, I've used processors with errata that have UB only if the power limit on the CPU is set below a threshold. If you go to this extreme, then everything is awful; you end up with a language definition that gives you nothing portable.

So, in practice, you want to limit what's UB and what's not UB. This is something that downstream standards from C can do if there's a need; for example, POSIX C is standard C with extra restrictions (notably that CHAR_BIT is 8, and WORD_BIT is at least 32).

The fact that no-one's created a standard that's like POSIX but with more UB defined (as defining behaviour is something that still meets UB standards for the C standard) and then persuaded both compiler authors and users to accept the use of that standard is telling.

Rust and GCC, two different ways

Posted Oct 7, 2021 16:12 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

It will in fact make it a language. Right now until there's only one implemntation, it's only a compiler for its own, self-defined, dialect. It's possible that work on some areas will be boosted by this and that others will slow down because instead of focusing on how things can be done in the existing compiler they will have to think about whether or not it makes sense in general. It's always harder.

Rust and GCC, two different ways

Posted Oct 9, 2021 4:58 UTC (Sat) by ncm (guest, #165) [Link] (2 responses)

Another potential benefit is that the Gccrs implementation has a chance to be much, much faster than rustc. That is not to say it will be, but there is enormous room for such improvement. The monumental slowness of the rustc compiler probably keeps it out of more production workflows than does its limited target-platform set.

Rust and GCC, two different ways

Posted Oct 11, 2021 16:29 UTC (Mon) by ssokolow (guest, #94568) [Link]

Bear in mind that they're already working on a Cranelift backend for it to speed up debug builds.

Rust and GCC, two different ways

Posted Oct 11, 2021 16:51 UTC (Mon) by moltonel (subscriber, #45207) [Link]

I think you underestimate how optimized rustc (the frontend) already is. Its performance is monitored very closely, and the gains indicate that the remaining room for improvement is small. It has very advanced incremental (re)compilation support, and is thoroughly multithreaded. The gccrs frontend will have a hard enough time catching up to and keeping up with rustc features, I wouldn't count on it keeping up with the optimization work.

Most of the time is spent in the backend, which is why rustc's cranelift backend (which predates rustc_codegen_gcc and focuses on quick but unoptimized compilation) is very interesting for debug builds. There are surely going to be differences between the GCC and LLVM backends, but judging by the Clang vs Gcc benchmark for C and C++, there's not going to be one clear winner. Same goes for the speed of the compiled code.

Rust is a complex language, it's never going to compile as fast as Go. It compiles about as fast as C++ (comparisons are hard, beware of apples-to-oranges), which is what you can hope for.

Rust and GCC, two different ways

Posted Oct 4, 2021 20:12 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (19 responses)

> 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.

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...)

Rust and GCC, two different ways

Posted Oct 9, 2021 18:55 UTC (Sat) by robert_s (subscriber, #42402) [Link] (5 responses)

If either of these projects bring us a rust implementation that doesn't have the bonkers bootstrapping-chain story that the official compiler has it'll be a wonderful thing.

Rust and GCC, two different ways

Posted Oct 9, 2021 22:22 UTC (Sat) by atnot (guest, #124910) [Link] (1 responses)

That's already pretty well solved by mrustc, a rust compiler written in c++ that's capable of bootstrapping rustc (and not much more)

https://github.com/thepowersgang/mrustc

Rust and GCC, two different ways

Posted Oct 14, 2021 17:47 UTC (Thu) by bluss (guest, #47454) [Link]

It's not exactly solved, since it requires constant work to keep up with rustc changes. Maybe "solved" as in theoretically solved, the bootstrap chain can and has been reproduced.

Rust and GCC, two different ways

Posted Oct 10, 2021 8:03 UTC (Sun) by ms_43 (subscriber, #99293) [Link] (2 responses)

Given that all FLOSS C++ compilers are implemented in C++ these days, there is less improvement in the bonkitude of the bootstrapping process to be had than one might naively assume.

Rust and GCC, two different ways

Posted Oct 11, 2021 16:33 UTC (Mon) by ssokolow (guest, #94568) [Link]

Generally, people are concerned about Trusting Trust attacks by that point, and resort to Diverse Double Compilation to provide a trustworthy starting point.

Rust and GCC, two different ways

Posted Oct 20, 2021 3:41 UTC (Wed) by pabs (subscriber, #43278) [Link]

The Bootstrappable Builds folks are working on a full bootstrap from a small number of bytes of bare metal machine code all the way up to a full Linux distro. They've already achieved quite a bit of that path.

https://bootstrappable.org/
https://github.com/fosslinux/live-bootstrap/blob/master/p...
https://github.com/oriansj/talk-notes/blob/master/live-bo...

Rust and GCC, two different ways

Posted Oct 15, 2021 2:34 UTC (Fri) by rhdxmr (guest, #44404) [Link]

gccrs, what an amazing project! I give a big applause to the maintainers and
contributors of this project. It's a very big project and it needs enormous
efforts to complete the compiler that can compile viable production-ready
programs. So it requires patience, guts, talent and belief.

I like Rust and I am a fan of GCC. But LLVM does not catch my fancy yet. So I
cheer this project and wish this project evolves steadily continuously and
achieves its goal eventually. I hope to see this project succeeds and want to
remind myself that there are many opensource leaders and there's a lot of
support for their efforts.

I am happy to see that there will be another option of rust compilers. The
diversity is 101 of opensource eco system. I like the traits of opensource eco
system: diversity, competition, supporters, liberty, etc...

I feel happy to know this news today.

Rust and GCC, two different ways

Posted Oct 17, 2021 0:36 UTC (Sun) by LWN_LVA16N (guest, #154801) [Link]

My experiences indicate that software support for at least two different hardware, languages, OS, or compilers (and several combinations of these) are essential to avoid developers unconciously biasing their design and implementation decisions on their personal preferences/existing personal hardware/language/compiler preferences. The best project I worked on was supported on four operating systems (with their captive compilers), five hardware platforms, and two different languages (assembler and a higher-level language). The addition of the second hardware, language, OS, compilers was really eye-opening. The third was a breeze (when accomplished). The fourth OS (done as an experiment) took only six weeks due to lessons learned. Supporting both the GCC and LLVM will provide insights on the unconcious design considerations that favor a specifc sets of OS, platform, and compiler configurations.