GCC Rust Monthly Report #9 August 2021 | Hacker News Reader

GCC Rust Monthly Report #9 August 2021

thephilbert.io

108 pointsingve124 comments

I wish the blog post opened with a sentence or two for context. This is a snip from the readme [1] on GitHub:

> Please note, the compiler is in a very early stage and not usable yet for compiling real Rust programs.

> gccrs is a full alternative implementation of the Rust language ontop of GCC with the goal to become fully upstream with the GNU toolchain.

I'm happy that there's work on alternative Rust compilers though!

[1] https://github.com/Rust-GCC/gccrs

It's a monthly report, it's target audience isn't people who're unaware of the project IMO.

It just got posted to hacker news which is full of people who are unaware of it. It doesn’t take much work to copy paste a paragraph from the readme into the post.

It is not the author's responsibility to change the content of a report because it got linked on a link aggregator website somewhere on the internet.

In fact, I'd go so far as to suggest people who feel like the content that's linked here is not too approachable to use the facilities provided to downvote the post to help other people avoid suboptimal content, if they feel it would be called for.

No it's not the author's responsibility, but if a few seconds of work could make the update accessible to far more people (and get more people excited about it), I'm not sure I see an argument against putting that context. Frankly, every article and blog post should be written that way.

Sure, it's not required, but how many people were turned off because they had no idea what the article was about?

Should all monthly reports for this project start with a paragraph introducing the project itself? I don't believe so. I don't think this article was written with the general HN userbase in mind, and there's nothing wrong with that.

> Should all monthly reports for this project start with a paragraph introducing the project itself?

Why not? A lot of projects do it. You also don't have to include that introduction in your RSS feeds, for the most avid readers, but it's very useful for newcomers.

Labor is very expensive, I'd rather it be spent working on gcc-rs rather than making reports about working on gcc-rs more elaborate. I do think that it'd be reasonable to expect anyone who's somewhat interested in what this is about to investigate themselves. Having said that, I don't believe that this kind of a post is necessarily well suited for being posted on HN exactly because it's not aimed towards a more general audience but rather it's specifically targeted towards people who're already interested in the project.

I agree with the hidden cost of PR labor for volunteer-run projects. But a summary of the project can be very short and efficient. Copied (shortened) from the README:

> gccrs is a full alternative implementation of the Rust language ontop of GCC with the goal to become fully upstream with the GNU toolchain. Please find the answers to frequently asked questions over on: https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

Two sentences like these would be more than enough to give a person passing by enough information to know what it's about, if it'd be useful for them, and whether they'd like to keep on reading.

I don't think that it should, but I will say that people do tend to appreciate it. That said, as you said, nothing wrong with not doing it. With Rust, we just made a template for these sorts of posts that include a sentence explaining what Rust is right at the start, so no burden for us.

Hi, this is Philip, the author of these reports. Sorry if this is confusing, but these are the reports I make weekly and present to Open Source Security, Embecosm and the GCC Steering committee. As this work is all open-source, I wanted to be as open as possible about developing such an ambitious project.

Another reason is that I wish to write up some document describing how the rust-language layers up, maybe a year from now. It is not very obvious to me what is bare metal rust vs compiler magic/library magic in the rust language. With these reports and my experience down the line, this might be interesting for people to read.

Please keep 'm coming. They provide very interesting reads. You might consider, in the first sentence, to change 'this project' to a link with a more high level document.

That's a good idea! Your comment means alot to me, thank you I put alot of work into my reports and will be trying to present them on my YouTube more regularly https://youtube.com/user/redzor812 I am really inspired by serenity os and Tim Morgan on natalie.

> Risk Impact (1-3) Likelihood (0-10) Risk (I * L)

> ... table ...

This gave me PTSD from FMEA analysis. Why not just write the arbitrary product only, or rank the risks, or don't rank them at all. No-one is forcing them why do this? Is this curriculum now?

Writing the product would make it confusing how they ranked them. Just ranking them would work but wouldn't represent the relative risk very well.

It seems fine to me, and it's just a multiplication of two numbers, that's not overwhelming.

Iirc there are people within the rust community that think this approach to using GCC is suboptimal, and that the reason this project survives is that some professors have decided to use this as an assignment.

If this is true , it wouldn't surprise me if this is the effect of them cargo-culting one of their Software-Engineering course

There are also those of us who are thrilled that a total alternative Rust parser is being written. A systems language should never be centralized to the degree Rust is.

why not

> there are people within the rust community that think this approach to using GCC is suboptimal,

This is true. There are also some (like me) who think both are great.

> the reason this project survives is that some professors have decided to use this as an assignment.

I am not sure that this is true.

The product indirectly tells you the criteria for accepting the risk as-is, but it doesn't give you any insight into how to reduce the risk. That's what severity and likelihood are for. You need all three together.

I am fine with guesstimates for likelihood and severity, but the product doesn't make sense. When two guesstimates are multiplied like that, you choose the terms to give the product you want, or vice versa. The concept of trying to do a distillation of a risk assessment to a number is flawed.

You're right that the product number is not a very meaningful value.

https://en.wikipedia.org/wiki/Risk_matrix

Take a look at this risk matrix. It's divided into cells that are each assigned a category. If you assigned numbers to it, you'd get conflicting results:

1. Possible (3) x Catastrophic (4) = Very High (12)

2. Likely (4) x Critical (3) = High (12)

In this case, 12 can mean either High or Very High. Therefore the category is more important than the product.

So basically, the product is only meaningful if the categories are defined in terms of it, which I don't think is common. Really, I should have said you need the category, rather than the product.

Why is Rustc not enough?

Rustc is based on LLVM. A GCC backend would target more architectures and be somewhat more optimized. Plus, a different implementation of a compiler frontend is, for some, a good thing to have for a language.

rustc is backend agnostic, and currently has: an LLVM backend, a Cretonne backend, and a GCC backend.

So rustc can already target _more_ architectures than this new GCC frontend, because it supports LLVM and Cretonne.

> a Cretonne backend

I think you mean Cranelift?

Oops, yes, Cretonne was renamed to Cranelift a while ago. For some reason I still call it Cretonne.

For now the only production-ready backend is the historical LLVM backends.

Because GCC is available on almost every platform that is in use, while LLVM is still much more limited.

There are tons of embedded platforms that get rust support from this work.

It's true that if this project succeeds, that would be an outcome, but it's probably worth noting that you'd really only have to add support for the GCC backend to do that, and not reimplement the frontend as well (parsing, type checking, lifetime checking, etc.). There's an unrelated project working to do that: https://github.com/antoyo/rustc_codegen_gcc that would likely yield those same benefits for less effort.

The "official" Rust frontend has a GCC backend that delivers this same value.

There might be other value that a separate Rust frontend delivers over the official one, but this is not it.

> this is not it

Wouldn't both approaches produce the same result (if they ever succeed to implement the whole spec)?

If GCC Rust is able to keep with Rust release cycle of new stable features every 6 weeks and new features / fixes on a nightly basis, sure.

Fair enough. Your parent comment seemed to imply otherwise :)

If you have only one compiler then the compiler becomes the standard, so you get an IE like situation where standards would be ignored and implementation details would be abused.

My question is why not have a GCC front end for all major used languages?

> so you get an IE like situation where standards would be ignored and implementation details would be abused

This is only the case when there already is a standard. If rustc is the only Rust compiler in existence, it effectively defines what Rust is. With one compiler there is no meaningful difference between implementation details and "standard" language behaviour.

> With one compiler there is no meaningful difference between implementation details and "standard" language behaviour.

That's the point.

There are odd edge cases that rustc has accepted by accident. Without a second opinion it's hard to tell what was intended, and what is a compiler bug.

To provide a second opinion, you can just open a rustc bug.

In fact, the Rust bug repository has thousands of opinions about thousands of things.

And if you disagree with the unilateral decisions of the rustc developers? "Go fork it or write your own"? Yeah that's what we're doing. Don't be surprised when what was often a taunt in Rust-related arguments actually ends up happening. :^P

> if you disagree with the unilateral decisions of the rustc developers? "Go fork it or write your own"? Yeah that's what we're doing

If that's what you want to do, that's great. If you experiment with new stuff, and it pans out, Rust itself might benefit from that.

Since your goal is implementing something that differs from "Rust", calling it "Rust", is misleading at best, I think is unethical, and given the intent, probably illegal in most of the world since "Rust" is a registered trademark... (IANAL but if you were implementing a frontend for Rust, you could maybe use it, but for an intentionally different language, doesn't sound like it)

I've been reading comments in this thread and i wonder what actual arguments you have against gccrs, if you have links to more detailed resources. As a Rust user, i'm happy people are working on alternative implementations so specs can get new eyes.

> implementing something that differs from "Rust" (...) I think is unethical, and given the intent, probably illegal

I don't understand this statement. One of the contributors said earlier in the thread something that sounds opposed to your interpretation:

> For inconsistencies, we have stated in our FAQ that if GCC rust does not behave the same as rustc. Then it is a bug with GCC rust.

Also, "your code is illegal" is not very much an ethics argument in my book. Digital weaponry like mass-surveillance systems are mostly legal, while harmless ThePirateBay/PopcornTime are illegal.

One of the main GCC rs devs wrote, I quote (https://news.ycombinator.com/item?id=28366445):

> And if you disagree with the unilateral decisions of the rustc developers? "Go fork it or write your own"? Yeah that's what we're doing.

I think that the main value of implementing a new Rust frontend, is discovering issues in the Rust spec.

They seem to, however, disagree with some Rust specification issues, and creating an incompatible frontend, not with the intent of making the spec better, but rather just doing something different.

They are calling this different thing "Rust", which I believe is a misleading, and unethical thing to do. (Its as if I make my own language, and call it C++). I think this could also be illegal, since Rust is a trademark of the Rust foundation, which if they don't defend, e.g., in cases like these, makes the trademark irrelevant, e.g., allowing corporations to fork Rust, change the language, and still use the Rust name, cause they did not enforce it here. But as mentioned IANAL, my only point is that you probably want to be very careful in most juristictions in the world about using a trademark in this way.

Others seem to also believe that finding issues in the Rust spec is one of the most valuable things for Rust that can come out of this project. But the main devs haven't been able to point at issues they have filled about it in Rust upstream (as opposed to other projects like have implemented rust frontends before, like mrustc, rust-analyzer, rustc_codegen_gcc, etc. which have found many bugs and filled many issues that have been fixed, submitted patches, etc.).

> I've been reading comments in this thread and i wonder what actual arguments you have against gccrs,

I don't have any arguments against gccrs.

I've been looking for arguments in favor of gccrs, but was not able to find any.

Most arguments mentioned here are incorrect, e.g., gcc-rs being necessary to get rustc access to more targets (incorrect since rustc_codegen_gcc is a thing), gcc-rs resulting in Rust spec improvements (incorrect since they aren't filling any bugs / helping in improving the spec), etc.

If you have an argument in favor of gccrs, please go ahead, I am all ears.

Is that person a gcc-rs dev? I didn't think that was true.

One argument in favor of gcc-rs is related to bootstrapping; right now you need both a previous Rust compiler, as well as a C compiler, to compile Rust. With gcc-rs, you need only gcc. I don't personally think that the bootstrapping situation is onerous, but there are some folks who are looking forward to that.

I thought that mrustc was a different more portable way of solving the bootstrapping problem, since it compiles Rust to C.

It is different, and is a great project. At the end of the day, with that strategy, you still end up with two compilers, not one single compiler, and some folks are attached to "we use this single compiler to build our entire base system." You also have to then continue the bootstrap chain to get up to current rustc, and I think folks hope that this project will track upstream more closely.

I also don't think that because it compiles to C it automatically supports all of the platforms gcc does, but I haven't personally investigated that because I don't have any of that exotic hardware.

EDIT: oh yeah and the project itself describes this stuff here https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

>I've been looking for arguments in favor of gccrs, but was not able to find any.

GCC can be faster in some cases and despite other claims there are many platforms that only work with GCC, I was offered in the past a job to work on implementing code optimizations for gcc by a company that had such a embeded board platform - so if Rust wants to run everywhere C runs then the community should try to explain the fanboys that gcc is not a bad thing.

> GCC can be faster in some cases

How?

The Rust compiler frontend already can use GCC as a backend.

This project - GCC rs - is a different frontend, which also happens to use GCC as a backend.

The number of targets and performance that both can have is the same.

So the argument "GCC can be faster than GCC" is illogical. You are talking about the same thing.

My bad, thanks for clarifying my confusion

Hello this is Philip the author of these reports and lead for the GCC Rust project. I feel its only fair to point out that the comment you link to the author is not a "main dev for gccrs".

I wrote part of the reasons for why I am working on gccrs here: https://news.ycombinator.com/item?id=28368924

Overall I feel sad that this effort has been perceived as some kind of attack against Rustc and its community by some. This effort of mine dates back to 2014 and then I was able to get quite alot of rust working in a short time but the language changed far too much to keep up as a solo effort. Since late 2018 I restarted the effort and seriously almost started the track to develop the a gcc backend using libgccjit, it is 100% something i have considered and thought through.

I will be giving a talk on this project at LPC if you wish to hear more about my reasons please listen then https://linuxplumbersconf.org/event/11/contributions/911/

>> And if you disagree with the unilateral decisions of the rustc developers? "Go fork it or write your own"? Yeah that's what we're doing.

I don't interpret that to mean they intend to insert breaking changes (especially since another comment and their FAQ directly contradicted that idea), but rather that they may explore different ways of implementing things, which i think is a great idea.

> But the main devs haven't been able to point at issues they have filled about it in Rust upstream

Maybe they're busy actually working on something and don't have time to look for specific instances? Or maybe a lot of questions/issues have been documented internally are have not been sufficiently reviewed yet to be opened upstream? There's a lot of room for interpretation here, but i see no reason to assume bad faith on their part.

> If you have an argument in favor of gccrs, please go ahead, I am all ears.

It's been rehearsed over and over, but if you want to build an actual standard, having many eyes/implementations is a good thing. Feedback from people trying different implementation approaches is crucial to making a specification robust.

>If rustc is the only Rust compiler in existence, it effectively defines what Rust is.

You can have 2 different version of the same compiler that makes 2 different things for the same code, or you can have a bugged compiler that on Thursday produces different output, I assume you notice now the problem with not having a standard and the documentation is "go read the compiler source code from tonight commit, yesterday code migtht not be fresh enough"

Why have Android when there is iOS? Why have Chrysler when there is Ford?

See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090

Once a language is mature, it's better to have various competing implementations, if just for the reason that no accidential implementation-defined behaviour sneaks into the specification.

> if just for the reason that no accidential implementation-defined behaviour sneaks into the specification

How's this going for languages with multiple compilers, such as C++?

Pretty well I must say, modern C++ is very portable across different compilers. I wrote a quite complex piece of code two months ago, I fully tested it under GCC and Clang, and it built under MSVC without having to change almost anything. It's quite worse under C though, given that the standard way less comprehensive. You really have to stay away from those pesky Glibc extensions, and lots of stuff in the Standard C library is pretty unsafe or straight out broken (like strcpy and friends).

Indeed, C++ has benefited enormously from having multiple implementations. If one compiler produces results different from another, generally speaking, you've just found an issue in that compiler. The multiple implementations serves as checks and balances in a way.

To be fair, off the top of my head, Clang and GCC:

- lex differently;

- have different baselines for what code even compiles: e.g. in GCC an out-of-range hex escape sequence in an integer character constant generates a warning; in Clang it generates an error.

Additionally, for a long time on Windows MinGW's std::random_device()() always returned 0, being a real-world depiction of <https://xkcd.com/221/>. So you compiled for Linux with GCC and everything was fine; then you compiled for Windows with MinGW and silently something broke, which resulted in a suspiciously big number of hash collisions.

Then again, those are illustrations of a poorly written standard, not of the idea of a standard, which has multiple implementations, being bad.

Overall it's going well. While Clang, GCC and MSVC sometimes have surprising behaviour differences, once you look this stuff up in the C or C++ spec, these are almost guraranteed to be marked as implementation-defined- or undefined-behaviour (and if not then it's a compiler bug). Even being able to pinpoint what is implementation-defined or what is undefined-behaviour is an advantage of having multiple independent compiler implementations.

Not enough CPUs supported by LLVM. (personally, I want m68k and MIPS-I)

So why don't you use the GCC backend for rustc?

LLVM does have an m68k backend, and there's an open PR on rustc to add it https://github.com/rust-lang/rust/pull/88321

Oh cool did they finally finish that? Time to get buildin' (I only use rust in my hobby so unfortunately it has to take a backseat a lot of the time)

One reason is that having multiple implementations can be useful to ferret out issues, a second is that the gcc framework wants to be a home for lots of language and that’s probably the reason why this was started, but the ecosystemic benefit is that gcc has a lot more (and more mature) support for rarer architectures and systems, and historically when companies provide a custom compiler for their weird-ass platform they do so using GCC (if only because it’s been there for way longer).

So an eventual gccrust would allow using rust on a much wider set of platforms, which is nice.

> One reason is that having multiple implementations can be useful to ferret out issues,

Do we have proof backing up this claim?

For example, a list of new previously-unrepported bugs that have been uncovered by the GCC Rust re-implementation of the Rust language frontend?

I have literally had to read compiler source code to find out Rust behavior before, more than once. That should never happen. The more implementations of a language there are, generally speaking, the better understood a language is. C++ has only benefited from having multiple compilers. If you're afraid of fragmentation or Rust dying as a result of this, I can assure you that historically, the exact opposite takes place.

> I have literally had to read compiler source code to find out Rust behavior before, more than once.

Every single time I had to do this, I opened a PR to the Rust reference with the fix. :shrug:

> That should never happen.

Sure, and the way this gets fixed is with documentation. GCC frontends have this same problem. I've had to read the GCC C++ frontend source code a million times already to figure out if it was standard compliant. When it wasn't, I sent a patch fixing it, instead of.... starting rewriting a new frontend from scratch.

Compared with GCC, the Rust frontend source code was almost every single time infinitely better documented. Many internal modules are actually intended to be read as documentation, and I do read the rendered compiler API docs every now and then when looking for something. The quality of GCC docs was... not great.

> C++ has only benefited from having multiple compilers.

C++ starting point was very different than Rust's.

> If you're afraid of fragmentation or Rust dying as a result of this, I can assure you that historically, the exact opposite takes place.

I'm not afraid, just curious about what value is in here.

I don't see why anyone would use GCC Rust, instead of the GCC backend, for anything. Most real-world Rust projects use 100s of crates.io dependencies. All real-word Rust projects I use, use nightly, and crates from crates.io that work on nightly. No idea how GCC Rust could achieve "daily" parity with Rust for anything practical. What's the strategy here?

Having multiple implementations is a sign of a healthy programming language. C++, Rust's primary competitor in this space has multiple implementations and all are used by somebody. In fact, if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io) then I don't see how it can overtake C++.

> if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io)

Why would that not be the case? crates.io is just a code repository like any other. You don't need crates.io to write/use Rust code, and crates.io has no specific requirement for a certain compiler.

It just so happens that currently only the main implementation of Rust language (rustc) can compile all of crates.io repository, but this could change in the future.

> Having multiple implementations is a sign of a healthy programming language

this is frequently taken as axiomatic but there's no actual support for it in reality. there are plenty of healthy single-implementation languages (go, rust, scala, erlang) and plenty of unhealthy multi-implementation languages (c, d, sql, javascript) to go alongside the healthy/multi (python, ruby) and unhealthy/single (php, i guess, i don't care about this quadrant very much)

> I have literally had to read compiler source code to find out Rust behavior before, more than once. That should never happen.

Can you point us to the documentation bugs that you filled upstream for each of these issues ?

I think it would make sense to tag them with "GCC Rust" or so, to be able to study them as a whole.

Plus I see the main value of GCC Rust in helping improve the Rust spec, so all bugs uncovered are definitely worth fixing.

I don't know of anything with rust, but e.g. the csmith project fuzzing three C compilers has been extremely effective at finding bugs by using disagreement between them as a litmus test (it works by generating C programs which are guaranteed to be standards-compliant but with an unknown output and comparing the execution outputs between the compilers).

Given that "Rust is the spec", and it changes on a daily bases, fuzzing it vs GCC Rust would give you a lot of disagreements, that would only tell you about the thousands of ways in which GCC Rust is not conforming with Rust.

I'm not sure what this tells you about Rust. By definition, it is conforming with itself.

Things that have been declared stable do not "change on a daily basis" though.

When was the latest Rust stable release - every 6 weeks - that did not change the "spec" at all, e.g., by adding new stable features or standard library APIs ?

It is true that on a six-week basis we add new things. I should have been more specific, haha. The point is that the language does not make daily breaking changes, which is a reputation that we still sometimes have even after all of these years of no longer doing so.

That said, you are still right that it is a thing that the gcc-rust developers will need to keep up with.

In any case, one could consider the Rust epochs as main synchronization points anyway.

I would not, because new things land in most editions, so it’s not like a particular edition refers to a stable subset of the whole language.

True, however with the enterprise hat I see epochs as LTS versions worthy to be the ones on CI/CD pipeline.

I think LTS versions are great, but see them as something very distinct from editions. It is something I would like to see us have eventually.

>> Given that "Rust is the spec" . . .

>> By definition, it is conforming with itself.

If the implementation is the specification, then how do you know what is a bug and what is a feature?

The root answer is the same as with a specification, which can also have bugs: the authors make this determination.

If you think you found a bug: you just open it.

Reviewers / authors / community determine whether its a bug in the compiler or in the spec or both, or not.

- How do you know that's something is a compiler bug? Compiler writers typically know.

- How do you know that's something is a spec bug? All Rust spec changes go through the RFC process. If the proposal doesn't mention the issue, then its probably a bug. There are also many people maintaining the Rust spec. These people usually know.

If nobody knows, you submit an RFC, explaining why you think is a bug. The community can then reading, and the appropriate teams can decide, and if it is merged, then it is a bug.

The fix lands at some point, and the fixed Language / standard library / implementation becomes Rust 1.X.Y.

Done.

---

This is much simpler than in C++, where if you think you found a bug... you could open it in clang or gcc, but if its a spec bug, then that's the wrong place, and it might get closed with "not a bug". Ok so you need to open it in the spec, which you can do, but without you being an ISO member (and paying) there is little on your hand to push this forward.... Anyways supposed this is fixed in the spec, you then re-open it in the implementation you cared about. This might be fixed, or not. Probably not, because it would make this implementation incompatible with another existing one (e.g. clang incompatible with GCC), and that other one could say "fixing this breaks too much code, we won't fix it", so.... now you need to coordinate a bugfix deployment across multiple implementations.

Even if you manage that, most fixes get backported, so that means these things introduce breaking changes in, e.g., old C++ standard versions, breaking old code that assumed those to be "stable", etc. And how these fixes are backported differs from compiler to compiler, so now you get a new set of incompatibilities.

Some compilers like clang, have flags to configure which fixes get applied and which aren't (e.g. -fabi-compat=...) so that the user can choose which versions with which specification patches of which other compilers the generated code should be compatible with.

How many bugs does the C++ spec have?

Thousands: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html

What happens if you screw your C++ compatibility settings when mixing code from different toolchains (e.g. a library compiled with clang on linux with a binary compiled with gcc or viceveersa) ? Undefined behavior.

The implementation shouldn't be the spec. Rust has a reference.

There is some really active discussion in the unsafe code wg repo by someone who is building an alternative compiler and has questions about corner cases. They largely seem like fruitful discussions.

These discussions are worth having.

Avoiding the discussions and "forking the frontend to do a different thing" because "omgz rustc docs are bad and rustc devs can't be trusted" doesn't seem too valuable to me (but I guess to some people).

Agreed completely.

Overall 2 major question come up about GCC Rust and they are not easy to answer but here is part of my perspective on the issue.

1. Keep up with rustc language development 2. How do we handle inconsistencies in behaviour

For inconsistencies, we have stated in our FAQ that if GCC rust does not behave the same as rustc. Then it is a bug with GCC rust. So it is not fruitful for us to raise issues with rustc until we can compile and run the test suite, even though I have some edge cases worth exploring.

Keeping up with the language is a more difficult one, and it depends on your outlook. From my perspective, I think it would be ideal if Rust would version the language. For example, every new release of rustc might include:

- New unstable lang features. - new language editions (like the upcoming 2021) - Stdlib updates and stabilisations. - Features like incremental compilation. - Bug fixes. - Dependencies updates like LLVM.

This is a lot of stuff that might change, and it's only the rust compiler version that gets updated for all of this work. I can see why this is the case, and it has benefits, but I am not sure rust editions are enough.

Currently, there is little to no benefit to picking a version of Rust to target. When new features are stabilised like const generics, this means state of the art in developing robust rust crates changes overnight, pushing the whole ecosystem onto the latest version of rustc. This is neat in some ways, but I am unsure how this will play out in the long run for Rust.

For me, an alternative front-end from GCC means backing from the GCC toolchain and a way to backport Rust to older versions of GCC. This also means that custom arch vendors whose only toolchains are custom GCC/binutils can also benefit from Rust as it will be part of the upstream project.

We can also explore things like language versioning with the gcc toolchain. Or explore some of the standardization efforts which I do think is important.

Other than that, big projects are fun, (I'm a huge fan of Andreas Kling serenity-os), there is a lot of low hanging fruit for people to make their mark on the compiler. Also, I thought I understood Rust, but it's exciting when you start getting into the nitty gritty.

A single point of failure is always enough.

How is rustc a single point of failure ?

Well for me personally, a big part of it is a conscious desire to reduce the unilateral control that the Rust Foundation and core rustc developers have over the language. I find some of their decisions actively harmful for a systems language, and with multiple alternative implementations, particularly egregious decisions might not be so easy to impose. This is why I'm glad that a parser is also being written rather than a mere backend.

In short, a big part of the motivation is a deliberate effort to decentralize Rust.

That, and 1. GCC historically generates better code than LLVM, and 2. GCC supports far more platforms.

> some of their decisions actively harmful for a systems language

That's quite a strong statement. What specifically do you dislike?

Among other things, async was done quite poorly imho and I know I'm not the only one to think so, and a huge pet peeve of mine is how rustc prevents you from turning off specific optimizations when they can be harmful to your code, e.g. strict aliasing, which actually makes unsafe code more unsafe by producing subtle bugs rather than predictable, deterministic behavior.

For some context, specifically, rustc has a "no compiler flags that alter language semantics" rule (editions are sorta this but also sorta not, it's too in the weeds for the purposes of this post, this would make a change an edition cannot make). What this person (I believe, I'm not gonna dig up the forum post to cross-check usernames) wants is something that they would describe as an optimization flag, but the rust/rustc devs would describe as a language dialect. This was therefore not accepted. (C and C++ compilers do have these sorts of flags.)

If alternative compilers had such a flag, you'd end up with code that was incompatible with rustc, leading to an ecosystem split. This is one of the major fears within the community about alternative implementations.

IIRC the GCC Rust developers have stated a desire for compatibility, and therefore I'm not sure that they would accept this flag either, but we'll just have to see I guess.

Rust must stabilize its ABI if it seeks to be a useful systems language. You usually don't have to worry about ABI for LLVM and GCC interaction, so why should you need to worry about rustc and gccrs interaction? C++ STL and MSVC are known exceptions. In other words, anything produced by gccrs will already be incompatible with rustc.

Yeah that was me I'm afraid. That said, I strongly disagree that -fno-strict-aliasing changes language semantics in an appreciable way, since using it to deliberately circumvent the aliasing rules still wouldn't be sanctioned by Rust. You'd just have a predictable, mostly acceptable form of "UB" rather than whatever glitter the compiler feels like farting into your face. If I was asking for a flag that broke existing code, I'd understand, but since this change is totally backwards compatible, I don't understand the objection.

ABI is a complete red herring. The issue is about taking source code that you've written in your almost-Rust and compiling it with Rustc, leading to miscompilations.

EDIT, responding to yours: it was explained in the thread, at length: https://internals.rust-lang.org/t/add-rustc-flag-to-disable-... it's not backwards compatible. The very first post is the language team co-lead explaining:

> Whether or not rustc makes use of the codegen backend's support for optimizing &mut using noalias, by specification and defition &mut is still an exclusive reference. Various parts of the language and library depend on that exclusivity for soundness. &mut is not the mechanism you're looking for.

Again, UB is UB, and if the author of said program wrote it to rely on -fno-strict-aliasing in gccrs, that's probably bad code. It doesn't mean, however, that -fno-strict-aliasing isn't useful.

The truth of the matter is that I'm horrified by stacked borrows and what it represents, because it will make unsafe code extremely painful to write and extremely brittle. Rust needs a way to opt-out of these aggressive optimizations, like every other systems language ever has had for the majority of their lifespans. A function attribute would be acceptable, but the truth is, Rust is not open to any such enhancements for unsafe code. They seem hell-bent on enforcing "safety" on deliberately unsafe code, even if it breaks that code in subtle ways.

EDIT: I have no interest in arguing further. This is a hopeless and frankly rather disheartening topic for me. Rust has brought out more strong emotions from me than any other language I have ever used. I suppose why it matters to me is because I see such potential in Rust, and I feel it's being taken down the wrong path. But, that's just my opinion.

> Rust needs a way to opt-out of these aggressive optimizations

As the next sentence of that very first post said:

> There is a way to tell the language exactly what you want: you can use unsafe, raw pointers, UnsafeCell, and abstractions built atop them.

And again, this is not about optimization, this is about semantics. What you want is a different semantics, which is why it is not something that we would accept as a flag. Rustc does already let you change what optimizations are done to your code (trivially: -C opt-level=n). That is not an issue. This just isn't about optimization.

Yes, it is about optimization. By your own admission, rustc allows you to set -C opt-level, and that would probably change semantics to the desired, but at significantly worse performance.

You don't seem to understand the concept of undefined behavior. What I'm trying to say is that even if rustc generates the correct output, the code could still officially be declared UB, just as it is now in debug mode. If it breaks logic that relies on the exclusivity of &mut, well, that's what UB does, it breaks things.

It is entirely an optimization option.

You're right that I think it would be nice if you could have multiple &muts created from raw pointers, but I'm not asking for that. The reason these things are issues at all is because Rust uses these references for things like RAII (e.g. &mut self in drop()), and there's no way to use raw pointers instead. If Rust provided a way to use raw pointers more easily in the places you need them, this would be a non-issue. But right now, the unsafe/safe boundary is very dangerous in Rust, so dangerous that I'm uncomfortable working in it even though I've worked in C and C++ for over a decade, and it's entirely a self-inflicted wound by the Rust devs.

> You don't seem to understand the concept of undefined behavior

Okay, now I am done here, like you said you were before this post.

Sorry, I was getting a bit frustrated, because I kept repeating my position, and you kept saying it affected semantics, whereas if it's UB either way, it hasn't really affecting semantics officially. Yeah I'm done too. I don't enjoy arguing, and Rust in particular never brings out the best in me.

I just found this issue in gccrs about strict aliasing, you might have some valuable input for it. https://github.com/Rust-GCC/gccrs/issues/653

> Rust must stabilize its ABI if it seeks to be a useful systems language.

? no it mustn't. what's the c++ abi

Thanks for another, dare I say mainstream, perspective on this.

> Well for me personally, a big part of it is a conscious desire to reduce the unilateral control that the Rust Foundation and core rustc developers have over the language

That's not really something they can do without hard-forking the language.

They either stick to what the reference implementation does, or don't. But as soon as they don't, it's essentially a forked language with incompatible nuances.

Are they working from a formal spec or are they comparing against rustc? Is anyone working on a spec for Rust 1.0 that could be standardized by ISO?

The Rust organization maintains, amongst other things, the Rust specification (called The Rust reference).

If someone wants to volunteer the 1000 expert man year required to, say in 10 years (with 100 experts), submit a probably 10 year outdated version of Rust that nobody is using anymore for ISO standardization, they are free to do so. Nobody is staying in their way.

I doubt anyone would care about evolving Rust in a way that's compatible with such ISO specification.

Most people interested in "specification" appear to be interested in doing things that add infinitely more value than an ISO specification, like actually formalizing the language in theorem provers / proof assistants, delivering an operational semantics specification like that of WASM, etc. These deliver almost instantaneous value in that they can be used to analyze existing Rust code for "formal" correctness, can be used to implement interpreters that verify and protect Rust programs at runtime, can be used to verify more aggressive optimizations that make Rust programs faster, can be used to extend the language with new powerful features that solve real problems and are built on a strong formal foundation, etc.

If you look at C and C++, which have millions of users, their ISO process only gives a tiny amount of people a lot of control over the language design and evolution. The only barrier of entry is paying the 1000$/year fee or so (no qualification, "Programming Language" background required, etc.). This type of process sounds to me diametrically opposite to anything Rust stands for.

But yeah, if someone wants to submit some subset of Rust for ISO standardization, create their own sub-community, and live happily ever after, they can definitely do it.

In some domains, if Rust wants a seat at C, C++, Ada table, that will be a required step.

And many of those domains are the exact ones rust would be a best fit in once mature. Flight controls, industrial control, medical devices etc. The places that want to eliminate undefined behavior at all costs would be interested in rust, though probably not crates.io.

Not really. Source: I use Rust in automotive where MISRA C is required, and the only thing we needed was to certify it.

No ISO standard required.

We actually also supplied a "fork" of the MISRA C doc, crossing out ~80% of it, since it was just stuff that is just not possible in safe Rust. We covered the remaining 20% with clippy lints.

Most of the certification involved is just basic stuff like "using version control system", "has unit test", "tests run on changes", "uses a linter" (really, as vague as just that...), etc. We tried to explain that we used "miri" to run most of our integration tests on top of an interpreter that detects all undefined behavior, but the current safety processes don't even have a concept for this, so we had to left this point out to pass certification (we still do it, it's just not something that's accounted for).

The process allows us to use crates.io crates "as is", even those with "unsafe code", as long as these have tests and we run them with our clippy linters enabled.

Basically, you just need to pay an entity to say that you don't have absurdly horrible software practices. That's where C and C++ have set the bar, and this bar is absurdly easy to meet with Rust, given that it has support for unit tests, most code available already has tests, has a linter built in, etc.

Good it is working for you, although I think it depends how burocratic the customer and government departments might be in each specific project.

There are many levels of certification. This project is in Central Europe.

A different team uses it in satellite micro controllers in the US, but I am not involved with that.

I don't know of any safety certification process that requires the programming language to have an ISO standard specification.

Thanks for sharing, I don't mean that they have, more from burocratic point of view, like checklists in RFPs, given conformance with stuff like these

https://www.highintegritysystems.com

> Supports IEC 61508, IEC 62304, FDA 510K

Hence why imagine Rust might need some kind of good for high integrity computing stamp, be it ISO, ECMA, or something else.

I think what's useful would be to have someone certify the Rust toolchain for some of these.

That's what's needed to enable anyone to develop safety critical apps without issues.

The problem is that most certification consultancies don't allow you to publish a certification such that everyone can use it. That puts them out of work.

The ones that have already certified Rust, make an upfront investment in the certification, and then can certify more users for a lot of money and little effort.

Having said this, for pretty much any project, you are going to deal with some of these certification entities anyways (the programming languages used are just a small part of the whole thing). I don't think Rust is cheaper or more expensive than the alternatives for these types of apps.

Customer RFPs can ask for anything. If they want it in C++, then that's how it is. Some RFPs actually explicitly ask for Rust nowadays (no C, no C++). But some RFPs ask for FORTH, or assembly, or don't really care at all about the language used. The customer needs to have people trained to "verify" the product that they are getting. If their people only know MISRA C, then that's what they are going to want, and none of this has anything to do with the actual technical pros/cons of any language; it's just a more complex social and engineering thing.

I see, thanks.

Thank you for bringing this expertise to this thread. I hope more folks learn about the ways these parts of the industry works.

Part of the safety story for compliance with standards like ISO 61508 and ISO 26262 is that you can demonstrate your toolchain had been validated and verified against something. In the case of C or C++, that usually means (among other things) demonstrating compliance with an accepted published standard like ISO 8859 or ISO 14882, and that is usually done through extensive testing with one or more audited and widely-acknowledged conformance test suites.

In the case of Rust, that would be "the standard is what the compiler does, so the compiler is by definition 100% conformant." Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. Liability is high when lives are at stake. This stuff is taken very seriously.

> In the case of C or C++, that usually means (among other things) demonstrating compliance with an accepted published standard like ISO 8859 or ISO 14882

Notice that the C++ standard has dozens of open bugs, some of them are actually due to incompatibilities within the standard itself, e.g., because it require implementations to comply to two different things simultaneously, but these are incompatible with each other. So in practice, it is impossible for any C++ compiler to actually comply to the spec.

So at the end the only thing any process ends up looking at, is that your compiler has lots of tests, and the process of developing it: do all tests have to pass before each release? etc.

Once such a test suite is verified, it becomes somethings others can use to say "my compiler passes it", but in practice, these test suites have bugs, and the test suites of gcc and clang are more comprehensive etc. Even if your compiler passes one such test suite, it won't pass certification if you don't have version control, testing running regularly, etc.

The rust compiler has a huge test suite. Every single change to the compiler must pass the test suite on some of the supported architectures, new releases of the compiler are tested against all the tests of the 40.000 libraries available in crates.io to make sure results don't change in code people actually write, etc.

> Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story.

This has been trivial to do in our experience. Just pay the fees. The standard at which the Rust toolchain development operates is much higher than what the highest safety certifications require, because the safety of these certifications is actually very low: their whole purpose is to avoid liability, so most of them are just a way to create a paper trail that shows that your process is not complete trash, so that if someone sues you, you can say that you were operating at the highest standards. Nothing more, nothing less. Nobody is interested in making these standards "good", that's not their purpose.

Practically, the only issue is that some certifications require you to certify every toolchain you want to use. So if you bump the stable Rust toolchain version from say 1.49 to 1.50, you need to re-certify. The process for recertifying is quick, since nothing covered during the certification process actually changed, but you have to pay the fees again and again and again.

I think this is braindead, but AFAIK all compilers for all languages have this problem.

What people generally mistake is that compilers are not certified - they are qualified tools. In this case, the regulators check if the vendor of the compiler uphold certain standards and practices - once. After that, you - the vendor - are allowed to update yourself.

https://ferrous-systems.com/ferrocene/ btw. is our effort to ship rustc with proper support required by most players in the industry.

>> Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. > This has been trivial to do in our experience. Just pay the fees.

Ah, MAX-8 syndrome. Just pay someone off and your airplane will be just fine. The safety auditors I deal with are little more rigourous.

> The process for recertifying is quick, since nothing covered during the certification process actually changed, but you have to pay the fees again and again and again.

I produce a qualified toolchain for a living. The qualification process for the toolchain itself is fairly simple: re-run all of the qualifying test suites (a process that takes maybe a week of elapsed time), analyse all of the results, and dispose of each and every new or unexpected result, a process that can take several elapsed weeks. The runtimes have to be certified: this requires additional tests to produce more evidence of 100% MC/DC coverage and faulty injection. The paperwork then has to be prepared, reviewed, and submitted. All in all a couple of full-time-engineer equivalent years. Once the auditors have given their stamp of approval, the toolchain can not change. Period.

We produce a safety-certified version of our OS and its SDK every two years or so, not because the auditor fees are high, but because it's a massive amount of work because people's lives are at stake, and the price of the loss of one life is just too damn high.

But go ahead and pay the right people off to sneak something by. Chances are good the people responsible will have moved on to damage something else by the time the corpses start piling up.

Can you summarize your claim ?

AFAICT, you are trying to say that current standardized certification processes aren't rigorous enough, and that you should be doing more.

I agree 100%, this is why we are using Rust, seL4, etc.

No one requires us to do this, but our projects using Rust have less bugs and issues than our past projects using C and C++.

(there are none)

> We actually also supplied a "fork" of the MISRA C doc, crossing out ~80% of it

As an example of what you'd cross out in MISRA I would expect things like the handling of switch.

MISRA says thou shalt supply default: cases in a switch. This ensures the switch is exhaustive, but at a terrible price, there are often scenarios in which there are only four possibilities A, B, C, D and MISRA obliges you to add default: and then assert this is never reached because A, B, C, D covers all the options.

Rust's match is exhaustive. If you write matches for A, B, C and D, and that compiles, there was no other option. If a library author tells Rust "Today there's A, B, C, D but maybe I need more later" with #[non_exhaustive] your A/B/C/D match doesn't compile, what if, says the compiler, there were more later? If the library author doesn't do that, but then adds E next month anyway, it's a backwards-incompatible change and gets flagged. So in Rust you get the benefit of that particular MISRA requirement built-in, always, and none of the inflexibility because the problem they're worried about was tackled by the programming language as a correctness issue.

Defensive programming. I think it is fine. But not when it is enforced by rules. The even sillier one is that any 'if-else if' has to have an 'else'.

Reply on news.ycombinator.com