An update on the GCC frontend for Rust

[Posted April 25, 2023 by corbet]

Philip Herron and Arthur Cohen have posted an update on the status of gccrs — the GCC frontend for the Rust language — and why it will not be a part of the upcoming GCC 13 release.

While all of this appears like a lot of work, we are confident in our progress and hope to get closer and closer to getting the core crate working in the next few months. There is also a lot of important work remaining in order to produce a valid Rust compiler, which is why we will spend the coming months focusing on the core crate as well as a borrow-checker implementation, and the development of the necessary tooling to allow us to try and pass the Rust 1.49 testsuite.
We aim to distribute the Rust 1.49 version of the standard library with our compiler in the next major GCC release, GCC 14, and hope to backport enough changes to the GCC 13 branch to get the core crate working in time for the GCC 13.2 release. This will enable users to easily start experimenting with the compiler for #![no_std] Rust programs and, hopefully, some embedded targets.

Repercussions for potential future C flags?

Posted Apr 26, 2023 1:01 UTC (Wed) by swilmet (subscriber, #98424) [Link] (19 responses)

I wonder, and don't know if it has already been discussed, but would this work be useful (eventually) to the C frontend as well?

To basically treat some parts of the C language as if it was Rust code, but with the C syntax.

The C syntax lacks a lot of Rust concepts of course, but nothing prevents from adding annotations to the code, in special comments that would be understood by the added CFLAGS. Also, the C language is not completely dead, the standard evolves.

Because it would be easier to refactor C code to such a subset-of-C-and-Rust-like language, rather than working in parallel with two main programming languages (C and Rust) in the same project.

Repercussions for potential future C flags?

Posted Apr 26, 2023 4:50 UTC (Wed) by tchernobog (guest, #73595) [Link] (17 responses)

It is a bit hard to do, because of the amount of assumptions rust code is allowed to take due to the absence (in not-unsafe code) of undefined behavior.

Unfortunately, C's design makes it very hard to take certain assumptions and even produce good warnings (producing errors would clearly break compiling against the standard).

C++ already does introduce a lot more restrictions, and compiling C code with the C++ compiler is commonly done for that reason.

If you want to build on top of C, probably an approach with a transpiler would be what you want, like Kotlin did with Java.

There is https://ziglang.org/ which is a good attempt in the right direction.

Repercussions for potential future C flags?

Posted Apr 26, 2023 7:46 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (2 responses)

It's probably more helpful (especially if you ever write unsafe Rust) to think of it as: all Rust code is forbidden from doing a LOT of things that would seem pretty innocuous in C, however Safe Rust is checked so there's no mental overhead, if you tried to do any of these forbidden things the compiler stops you. Unsafe Rust has the exact same rules, but nobody else is ensuring you follow them. If you break any of the rules it's your fault when the program misbehaves, as a result writing Unsafe Rust is definitely harder to get right than C - but the idea is that you should need this rarely if at all.

Aliasing is the most obvious example of something forbidden in Rust but normal in C. Merely creating a mutable alias (e.g. int foo = 1; int *bar = &foo; in C) is forbidden in Rust. Even if you promise never to actually mutate it - even if the compiler can easily see that you don't - the construction of this Wrong Thing puts you on the far side of the rules.

Repercussions for potential future C flags?

Posted Apr 26, 2023 8:39 UTC (Wed) by matthias (subscriber, #94967) [Link] (1 responses)

> Merely creating a mutable alias (e.g. int foo = 1; int *bar = &foo; in C) is forbidden in Rust.

Fortunately, the borrow checker will prevent creating aliases to mutable references, even when you are using unsafe rust. In unsafe rust you will usually deal with raw pointers. And it is perfectly valid to have aliasing raw pointers as long as you take care of data races. Thus you basically have to uphold the same invariants as in unsafe C. [*]

Of course, at the boundary to safe code you have to ensure that you only create one mutable reference from your raw pointer, but that should be easy to comply with. And you are not allowed to mutate the state through your raw pointer while there exist any references (mutable or shared). So, it should not be that hard after all to create correct unsafe rust code. And -- as you said -- you will rarely need it at all and you can therefore be extra cautious at the places where you really need this.

[*] There is no such thing as safe C ;)

Repercussions for potential future C flags?

Posted May 3, 2023 11:13 UTC (Wed) by ssokolow (guest, #94568) [Link]

Not quite. There are ways to synthesize aliasing pointers from raw pointers in unsafe Rust which are UB that the optimizer may recognize but the type-checker can't catch.

As Aria Beingessner has written about in Rust's Unsafe Pointer Types Need An Overhaul, there definitely is improvement to be done.

I've seen at least one talk demonstrating examples of how stuff like that in unsafe Rust can be a footgun because there's an intuitively obvious way to do something, but it results in something like "casting through a reference" and, thus, invokes undefined behaviour. (With the proper solution being to use some function under std::ptr to manipulate the raw pointer directly.)

Repercussions for potential future C flags?

Posted Apr 26, 2023 10:54 UTC (Wed) by swilmet (subscriber, #98424) [Link] (13 responses)

Or, what about a transpiler C --> Rust.

Not for the full C specification, just a very small subset of C at the beginning. Like starting with a blank page, but keeping the familiar syntax of C.

Repercussions for potential future C flags?

Posted Apr 26, 2023 11:46 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

Something along the lines of C2Rust? Transpiles C to Unsafe Rust that's supposed to be semantically the same, and then you are able to gradually refactor the Rust from a very literal interpretation of your C into good-quality Rust (possibly while maintaining the C interface - depends on what you're doing).

Repercussions for potential future C flags?

Posted Apr 26, 2023 13:53 UTC (Wed) by swilmet (subscriber, #98424) [Link] (3 responses)

Interesting, but I had more in mind a transpiler for: subset of C --> safe Rust code.

And gradually "oxidizing" a C codebase to such safe subset of C.

Repercussions for potential future C flags?

Posted Apr 26, 2023 14:24 UTC (Wed) by ojeda (subscriber, #143370) [Link] (2 responses)

A few of us within WG14 support introducing a "safe" subset (or similar approaches or features) within ISO C.

However, even if we did get enough support for something like that, please note that if it is really just a subset of current C, then there is little you would be able to do inside it.

For instance, most C functions that take a pointer would be unsafe (in Rust terms). Similarly, a lot of expressions would not be allowed unless you remove the UB from them somehow, which in turn may make them surprising, even if only in terms of expected codegen.

Repercussions for potential future C flags?

Posted Apr 26, 2023 16:52 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (1 responses)

What would be the intended application of such a "safe subset" ?

Where we can afford to give up general applicability I would prefer the trade WUFFS takes, where we get to be arguably even safer than Rust and go real, real fast (because we proved so much about the code at compile time, our optimisations can be extremely aggressive with no risk of nasty surprises) in exchange for just writing off general purpose software development entirely as a goal.

I think we do too much general purpose software development and so we lose sight of the fact that many of our problems are only daunting (or outright insurmountable) in the context of general purpose software, if we're OK with saying no, I only want to (for example) turn blobs of data into RGB pixels, or (another example) turn PCM audio into different PCM audio, many of the trickiest problems we have are quite tractable. Not everybody needs to write the Linux kernel, the Linux kernel already exists, many of us could write something less... comprehensive ? amorphous ?

Repercussions for potential future C flags?

Posted May 3, 2023 10:47 UTC (Wed) by ssokolow (guest, #94568) [Link]

Agreed.

As someone who came to Rust from languages like Python for the maintainability (Haskell's type system may be stronger, but its ecosystem ethos is less suitable and the GC makes it much less suited to writing modules I can also reuse in things like PyQt GUI apps), rather than the performance, my ideal world would would involve a version of WUFFS that's written in and compiles to Rust.

(So that I don't sacrifice the comfortable workflow and ease-of-cross-compilation from working on a Rust project where the only C dependency is that final link stage between the standard library and the platform libc to access stuff like the ABI stability boundary for the Windows or macOS or BSD kernels.)

Repercussions for potential future C flags?

Posted Apr 26, 2023 11:53 UTC (Wed) by smoogen (subscriber, #97) [Link] (5 responses)

Again the issue is with the large amounts of undefined behaviour in the C standard. That undefined behaviour is usually there for one of the following reasons:
1. There are differences in how architectures actually do something so if you define a specific behaviour your compiler will be useless.
2. Some architetures actually do different things depending on outside factors, so again defining the behaviour will result in failure.
3. There are strong differences of opinion on what the proper thing to do is. While these usually get parlayed by various people as 'vested interests' from some company or manufacturer, they are usually the same as vi vs emacs. People's brains can come up with specific ways which solve a problem for them better and they stick to it.

Repercussions for potential future C flags?

Posted Apr 26, 2023 12:06 UTC (Wed) by Wol (subscriber, #4433) [Link] (3 responses)

And surely much of that could be fixed?

(1) should be a simple case of "hardware defined". Maybe a switch to force counter-intuitive behaviour if required. If you rely on ones-complement and enable that flag on a twos-complement piece of hardware, you deserve what you get ...
(2) this might be a case of (1) or it might not. I can imagine - SCADA in particular - where you don't know what the hardware is going to do. Maybe you shouldn't be using C :-)
(3) make this a case of "if you don't ask you don't get". Compilers must implement at least one defined behaviour, and have a compiler flag to enforce it. Asking for an unimplemented behaviour is a compile time error, not asking is you get what you asked for :-)

Option (3) in particular is likely to result in a marked increase in the quality of C programs, I would have thought ... and a marked DEcrease in the number of programs that stop working when the compiler is upgraded :-)

Cheers,
Wol

Repercussions for potential future C flags?

Posted Apr 27, 2023 11:32 UTC (Thu) by calumapplepie (guest, #143655) [Link] (2 responses)

Making behavior dependent upon compiler flags is a big mistake. You should be able to tell what code will do based on the code: if some distributor's default mixes in flags you weren't expecting, that then change what your code does, life won't be great.

Repercussions for potential future C flags?

Posted Apr 27, 2023 12:40 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> You should be able to tell what code will do based on the code

I couldn't agree more. But if you actually read the context, how on earth are you supposed to tell what the code will do if it's undefined? Is it going to format your hard drive? Better a compiler switch, than random changes depending on the phase of the moon ...

Cheers,
Wol

Repercussions for potential future C flags?

Posted Apr 27, 2023 19:28 UTC (Thu) by khim (subscriber, #9252) [Link]

> But if you actually read the context, how on earth are you supposed to tell what the code will do if it's undefined?

Easy: you just look on the assembler code.

That's, ultimately, the reason C is dead: it's not technical, it's social.

Lots of people are not looking on C program as, well, C program.

Instead they think about machine code generated and for them C code, C compiler and C itself is merely a tool which allows them to produce assembler code they want.

And if they couldn't find a “nice”, documented way to achieve what they want they would just write program full of UBs and tweak it till generated assembler wouldn't be satisfying.

And, of course, it actually makes it impossible to write compiler which wouldn't mishandle such programs.

That's basically why C couldn't be fixed by changing the specs. Unless you are doing what Rust is doing all changes to the specs wouldn't amount to much.

Repercussions for potential future C flags?

Posted May 3, 2023 11:03 UTC (Wed) by ssokolow (guest, #94568) [Link]

3. There are strong differences of opinion on what the proper thing to do is. While these usually get parlayed by various people as 'vested interests' from some company or manufacturer, they are usually the same as vi vs emacs. People's brains can come up with specific ways which solve a problem for them better and they stick to it.

That's a bit of an understatement, given what a soul-crushing struggle it was just to get #embed, rife with things like double standards and bad-faith acting... and #embed is a fairly isolated feature with minimal effect on existing behaviours and features.

Repercussions for potential future C flags?

Posted Apr 26, 2023 12:56 UTC (Wed) by ballombe (subscriber, #9523) [Link] (1 responses)

Consider a<<=b. if the compiler output the local asm equivalent of 'shl a,b',
if b >= sizeof(a)*8, the result will depends on the CPU.
So if you want to remove the 'hardware defined behaviour', you will have to make this operation
several time slower than needed on some CPU.
So your transpiler might generate code that is much slower than the original C code.

Repercussions for potential future C flags?

Posted Apr 26, 2023 13:44 UTC (Wed) by swilmet (subscriber, #98424) [Link]

> So your transpiler might generate code that is much slower than the original C code.

If what the transpiler takes as input is a proper subset of C, then a full C compiler can be used too, and the transpiler to Rust would serve as additional sanity checks (like other static analysis tools: Coverity Scan, etc).

Repercussions for potential future C flags?

Posted Apr 26, 2023 14:51 UTC (Wed) by cyperpunks (subscriber, #39406) [Link]

Rust is here and it works very, very well. It resolves a large number of issues in C/C++, start to port your code today :-)

An update on the GCC frontend for Rust

Posted Apr 26, 2023 6:48 UTC (Wed) by taladar (subscriber, #68407) [Link] (8 responses)

So GCC 13 has not even been released yet but they plan to ship a version of the standard library that is already 20 releases outdated (so 120 weeks old) now with the GCC 14 release, presumably because their compiler can not handle some newer language constructs? Is there a particular reason to put that much effort into making a project that won't be able to compile anything that is still maintained on crates.io by the time it is released?

An update on the GCC frontend for Rust

Posted Apr 26, 2023 8:11 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

It seems unlikely that all the rugged stuff which has a very conservative Minimum Supported Rust Version will go away in the intervening months. And not everybody who writes a new major version with a higher MSRV abandons all older versions. For at least the foreseeable future, this frontend won't be the premier way to use Rust on mainstream systems, so hence the prioritisation of making core work. Core won't get you far building an RDBMS or a web server but you don't need much else to run the Rust program you wrote for a $1 micro controller with a couple of sensors and a relay and _that_ hardware probably doesn't have an LLVM target, so without GCC Rust is never coming.

Is it your understanding that the idea of this frontend is to freeze forever at Rust 1.49? Because that doesn't seem to be what its maintainers are saying, nor anybody else. Necessarily to get from A to B we must pass through intermediate points. "No Rust" to "Rust 1.49" seems like a lot of progress to me, taking a great many years for the Rust project so it's not a surprise that this team can't repeat it in a few weeks.

Old version

Posted Apr 26, 2023 13:47 UTC (Wed) by corbet (editor, #1) [Link] (6 responses)

You have to start somewhere; Rust is a moving target and if they try to keep up with it from the beginning they will never get to anything useful. The developers have said that they have more current Rust versions in mind, but they have a milestone to get to first.

Old version

Posted Apr 26, 2023 14:54 UTC (Wed) by cyperpunks (subscriber, #39406) [Link] (5 responses)

The integration seems to be under controll.
Rust will be here the next 50-100 years (much longer than C/C++).
It's better to use more time and do it right than rush a incomplete thing.

Old version

Posted Apr 26, 2023 17:44 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (4 responses)

> Rust will be here the next 50-100 years (much longer than C/C++).

Funny how many developers have high expectations for their pet language. We've heard similar things for so many languages in the past. It's equally possible that in 30 years someone will say "what's this metal box?" and someone will respond "oh it's and old device that was called a computer, don't touch it it's full of rust" and then the language will wear its name marvelously :-)

On the opposite I predict that in the next decades, the most accessible languages will be swallowed by AI generators, not for the language but because they're addressing simple problems, and that over time it will be figured that generating code for high-level languages and fast moving targets is a pain, and that languages that impose lots of constraints do not bring any benefit anymore once you remove the human from the equation. You'll still keep a small percentage of human developers (basically the same that continue to use asm and low-level C for very specific stuff) and code generators will produce code for extremely permissive languages, possibly even C.

Old version

Posted Apr 26, 2023 18:06 UTC (Wed) by Wol (subscriber, #4433) [Link]

> On the opposite I predict that in the next decades, the most accessible languages will be swallowed by AI generators, not for the language but because they're addressing simple problems, and that over time it will be figured that generating code for high-level languages and fast moving targets is a pain, and that languages that impose lots of constraints do not bring any benefit anymore once you remove the human from the equation.

And how many times have we heard that :-) Was it the 1980s? Was it called "The Last One"? And given what we're hearing about AI, that it's biased, that it makes mistakes, that - basically - it's just as crap as humans are at actually getting things right, why do you think history is going to turn out different THIS time round, as opposed to all the previous times?

Assembly code replaced machine code. 3GLs replaced assembly. 4GLs tried to replace 3GLs and failed. AI is trying to replace 3GLs ... I fully expect it to fail ...

There's 3GLs and there's 3GLs. There's the "plenty of rope to hang yourself" ones - C, C++, Pick, ... There's the formally mathematical ones, Fortran, APL, SQL, ...

And at the end of the day, I think the biggest fly in the ointment is the Cretan Paradox, Godel's incompleteness theorem. The fact that logic is not logical is going to kill any attempt to write "The Last One".

Cheers,
Wol

Old version

Posted Apr 27, 2023 12:33 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

So I agree that you shouldn't expect Rust to somehow be an important language in 100 years, a far greater distance in time than from when Grace Hopper suggested the machine should convert the program into machine code (rather than people doing that work) to today.

But Computation is much more fundamental than a particular programming language, or even a programming paradigm. Even if you're much more sceptical of Church-Turing than I am, it's a very important idea, likely up there with zero (the additive identity) in terms of not being a fad.

And I don't think the AI generators swallow up "accessible languages". Cobbling together stuff that maybe kinda sorta works in C++ is easier because "No, that's wrong" is rare, IFNDR means most likely your program compiles despite being nonsense, and it just has mysterious bugs which these generative models can't help you with beyond more haphazard changes that may introduce yet more mysterious bugs.

Old version

Posted Apr 28, 2023 6:17 UTC (Fri) by roc (subscriber, #30627) [Link] (1 responses)

On the contrary, AI code generators benefit from targeting languages with lots of constraints. Those languages move work from whoever's reviewing and debugging the code (humans, today) to whoever's writing the code (AI).

Old version

Posted May 2, 2023 19:26 UTC (Tue) by immibis (subscriber, #105511) [Link]

That depends on whether you expect the AI-generated code to work or not. In my experience, the code still won't work, but now the compiler will tell you instead of the runtime environment.