Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC Rust: GCC Front-End for Rust

github.com

Post reply on HN
Print view View original

111–120 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#111

Post by jdoerfert »

davidhyde wrote: post #103
steveklabnik wrote: post #68

Earlier quoted context omitted.

I don't know the root cause of the noalias miscompilation, the thing I was referring to is https://github.com/rust-lang/rust/issues/28728 TL;DR: C++ says that an infinite loop with no side effects is UB, Rust does not. Empty loops in Rust will disappear entirely when they should really loop forever. (I edited my comment slightly because, re-reading, "blindly" sounds too negative.)

Great point! If anyone is curious about how to write an “empty” loop that is not compiled away, I've seen this common implementation that doesn’t even need the standard library: loop { core::sync::atomic::compiler_fence( core::sync::atomic::Ordering::SeqCst); }

Since https://reviews.llvm.org/D86841, ~ Aug 2020, Clang is able to reason about the forward progress guarantees of the input. For the LLVM-IR handling see https://reviews.llvm.org/D86233. While we are still adding more fine-grained support of different language standards and corner cases, e.g., constant loop condition in C vs. C++, you should be able to tell LLVM a loop is allowed to loop forever w/o side-effect. In fact, that is the new default. That said, LLVM still removes calls to functions without side effect unconditionally. We are working on that, i.a., https://reviews.llvm.org/D94106.

Re: GCC Rust: GCC Front-End for Rust

#112

Post by jdoerfert »

saagarjha wrote: post #104
volta87 wrote: post #102

Earlier quoted context omitted.

Notice that in C and C++ loops that might not terminate are UB, while in Rust they are just infinite loops. So there is a significant difference in semantics between Rust and C/C++ here.

C and C++ actually differ in semantics here; C allows infinite loops that are controlled by a constant expression.

Generally, yes. Though, as always, these things are hard to summarize in one sentence and depend on the standard version (pre/post C++11). This post might shed some light on the options we are considering for Clang right now: https://reviews.llvm.org/D94367#2489090

Re: GCC Rust: GCC Front-End for Rust

#113

Post by ncmncm »

ibraheemdev wrote: post #67

There was a thread posted on the rust forum a while back that laid out the goals of this project [0]: > A friend of mine (Luke) has been talking about the need for a Rust frontend for GCC to allow Rust to replace C in more places, such as system software. To allow some types of safety-critical software to be written in Rust, the GCC frontend would need to be an independent implementation of Rust, since the relevant s…

It would be a grave error to have coded the Rust frontend to Gcc in C (or, as written above, "in c"). Gcc is now a C++ codebase, and new components should be coded in modern C++, for better productivity, performance, safety, and maintainability.

(You might prefer not to consider modern C++ more productive, performant, safe, and maintainable than C (and reflexively downvote), but the statement remains true: Gcc did transition to C++, for reasons. And, all the improvements that have kept Gcc competitive with Clang were done, since. And, Clang and LLVM are also coded in C++, also for reasons.)

Re: GCC Rust: GCC Front-End for Rust

#114

Post by nicoburns »

chubot wrote: post #81
tumdum_ wrote: post #76

Earlier quoted context omitted.

No stable ABI makes distributing shared libraries harder :/

If you want to distributed stable shared libraries, you write to the C ABI, not the C++ ABI. Likewise Rust users should write to the C ABI for stabled shared libraries. (I believe there are a bunch of mechanisms to do that, though I'm not really a Rust user) For example look at what KDE does: https://community.kde.org/Policies/Binary_Compatibility_Issu... Yes, you have to do a lot of extra work. That's working as int…

There's also the possibility of an opt-in stable ABI (using the `repr` mechanism). I personally really like the idea of there being an opt-in cross-language ABI at a higher level (or supporting more use cases) than the C ABI (which is quite limiting).

Re: GCC Rust: GCC Front-End for Rust

#115

Post by zzz11 »

pm215 wrote: post #61
bonzini wrote: post #46

Earlier quoted context omitted.

A compiler front-end is pretty boring software in terms of memory safety. Lots of things that the front-end allocates are simply never freed. Have you ever seen GCC crash with a SIGSEGV? I rarely did even when I used to be a GCC developer.

Indeed. Notoriously, a SEGV in gcc during compilation used to usually mean "your hardware is flaky": https://tldp.org/FAQ/sig11/html/index.html

That was before the invention of fuzzing.

Re: GCC Rust: GCC Front-End for Rust

#117

Post by turminal »

steveklabnik wrote: post #78
thesuperbigfrog wrote: post #75

Earlier quoted context omitted.

Exactly. The C++ standard ( https://isocpp.org/std/the-standard ) is the specification that describes what a compiler must do to implement a particular "version" of C++ (for example, C++ 20). Just as there is a C++ standard and multiple C++ compilers that implement the standard, there should be a Rust standard and multiple implementations. This is the way that mature languages work.

This is the way that very few languages work. Python is a great example of an extremely popular, mature language that does not work this way. It is unclear that most people think that this sort of process is required for “maturity.” If this is the benchmark, then among popular languages you basically have C, C++, C#, JavaScript, and... is that it?

The other languages without a spec don't market themselves a C/C++ replacement or as systems languages.

Having a webapp depend on a CPython implementation detail is very different from having a kernel depend on an implementation detail of a language without a spec that was used to implement it.

And languages actually stack on top of each other. Imagine depending on a CPython implementation detail that depends on an implementation detail of a specific C compiler. Those things do happen and they make programmers' lives miserable sometimes, but imagine how often that would happen if C didn't have a spec that all compilers strive to implement.

Re: GCC Rust: GCC Front-End for Rust

#118

Post by JoshTriplett »

not2b wrote: post #30
vlovich123 wrote: post #12

What I really hope is that the Rust community doesn’t go out of its way to make this easier. Communicate and let value come back but there’s an significant amount of value in keeping a single backend relies on. CPython has done the Python community a lot of good by keeping one official compiler/tool chain (despite the great work done by projects like JPython/PyPy). The only way to do this properly, if desirable, is t…

Strongly disagree. It will only benefit the language to have more than one quality implementation. C++ has benefited hugely by the competition between g++ and clang; both compilers have gotten much, much better. To be fair, it will take a while before the GCC Rust front end is competitive, but for some purposes it doesn't have to be, like bootstrapping. If "progress" means "rapidly add more and more new features in e…

> It will only benefit the language to have more than one quality implementation.

As long as "quality implementation" means "implements the entire Rust language and not a subset".

Because otherwise, people will start getting requests to avoid using features that the non-standard Rust toolchain doesn't support.

Re: GCC Rust: GCC Front-End for Rust

#119

Post by ncmncm »

pjmlp wrote: post #71
turminal wrote: post #57

Earlier quoted context omitted.

>If "progress" means "rapidly add more and more new features in each release", multiple implementations will slow things down This has to happen at some point anyway otherwise we'll just get another C++. And I don't think Rust would benefit from that. New languages are designed to fix problems with the old ones, not to replicate them after all. I just hope the designers will choose that point wisely.

In some extent, given the use of macros and Haskell like libraries, it is already another C++. Besides, if Rust doesn't become another C++, it won't fulfil the industry needs that C++ caters for, thus while it might become a success in some domain, it won't replace C++ in the OS and GPGPU SDKs.

Rust will not in any case replace C++, in any core application area.

Rust might move in alongside C++, in some, in time. Or, Rust could still very possibly fizzle. That would be the normal course of events for a new language, barring a miracle as was dispensed to Javascript, Java, C++, and vanishingly few others.

Will Dart survive and thrive? Kotlin? Scala? Clojure? Go? All doubtful, based on prior experience. Having a lot of code and a lot of users does not seem to suffice. Many other languages had those, and faded. Ada even had $billions in backing, and faded.

What we can say confidently about Rust's future is that it is not certain to fade. The miracle has come in less deserving cases.

Post reply on HN