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

151–160 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#151

Post by gpderetta »

souprock wrote: post #150
jdoerfert wrote: post #112

Earlier quoted context omitted.

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

Just what is gained by failing to loop forever? It seems like a really low-value optimization. Nearly always, the optimization would violate the programmer's intent or it would change an ordinary bug into a confusing bug. An infinite loop is not very many bytes on any processor. The standard may allow the generation of insane code, but a decent-quality compiler does not do so. The standard ought to be fixed.

The infinite loop being UB was added because it prevents some important code motion optimizations and makes it hard to reason about the memory model. You can find the details on the papers leading to the C++11 memory model.

Re: GCC Rust: GCC Front-End for Rust

#152

Post by souprock »

gpderetta wrote: post #151
souprock wrote: post #150

Earlier quoted context omitted.

Just what is gained by failing to loop forever? It seems like a really low-value optimization. Nearly always, the optimization would violate the programmer's intent or it would change an ordinary bug into a confusing bug. An infinite loop is not very many bytes on any processor. The standard may allow the generation of insane code, but a decent-quality compiler does not do so. The standard ought to be fixed.

The infinite loop being UB was added because it prevents some important code motion optimizations and makes it hard to reason about the memory model. You can find the details on the papers leading to the C++11 memory model.

Uh, so what?

Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard?

Actually, this is worse. Letting the loop be UB is like letting a true "if" be UB. Just never mind the code actually written; surely it doesn't mean what it says.

Re: GCC Rust: GCC Front-End for Rust

#153

Post by gpderetta »

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…

I don't understand what is your point. The KDE example you have linked shows that you can in fact guarantee a stable C++ ABI (although it requires a lot of care). The fact that they go through all the trouble is a hint that a C ABI is in fact too restrictive and not expressive enough for a large framework like KDE.

Specifically KDE relies (among other things) on the ABI stability of the layout of virtual tables which is certainly not part of the C ABI.

Re: GCC Rust: GCC Front-End for Rust

#154

Post by gpderetta »

strongdenial wrote: post #26
varajelle wrote: post #22

Earlier quoted context omitted.

> There is absolutely no reason why the GCC front-end needs to be written in Rust. How about memory safety and fearless concurrency?

Not a requirement for a GCC front-end and certainly not worth sacrificing a potentially faster path to bootstrapping the official compiler implementation. You should be worried about the ease by which various systems can bootstrap and adopt the language, which is a mostly solved problem for C/C++ but not a given for Rust itself. Some maintainers will absolutely refuse bootstrapping off of binary artifacts compiled fr…

bootstrapping is important, but I believe that GCC already allows non-primary (i.e. optional) languages frontends to be written in other languages. The ADA front end is written in ADA for example.

Re: GCC Rust: GCC Front-End for Rust

#155

Post by pjmlp »

nicoburns wrote: post #114
chubot wrote: post #81

Earlier quoted context omitted.

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

For example, COM/UWP on Windows, Binder on Android.

Re: GCC Rust: GCC Front-End for Rust

#157

Post by volta87 »

gpderetta wrote: post #151
souprock wrote: post #150

Earlier quoted context omitted.

Just what is gained by failing to loop forever? It seems like a really low-value optimization. Nearly always, the optimization would violate the programmer's intent or it would change an ordinary bug into a confusing bug. An infinite loop is not very many bytes on any processor. The standard may allow the generation of insane code, but a decent-quality compiler does not do so. The standard ought to be fixed.

The infinite loop being UB was added because it prevents some important code motion optimizations and makes it hard to reason about the memory model. You can find the details on the papers leading to the C++11 memory model.

> The infinite loop being UB was added because it prevents some important code motion optimizations

Which ones?

If this optimizations are so important, how come Rust was designed in such a way to make them impossible? Also, how does this fit, e.g., the benchmark game results which show that Rust is faster than C for all benchmarks considered there ?

Re: GCC Rust: GCC Front-End for Rust

#159

Post by CodesInChaos »

steveklabnik wrote: post #35
oconnor663 wrote: post #14

Earlier quoted context omitted.

The LLVM-based Rust compiler uses a lot of unstable/nightly-only Rust features internally. So even if this project got to the point where it could compile all stable Rust programs, I think it would take quite a bit more work than that to be able to compile `rustc` itself. (It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference?)

> It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference? It might. There are at least two major things off the top of my head, regarding libstd: 1. specialization is needed for performance around String and &str 2. const generics are needed to support some trait implementations We currently allow some stuff like this to leak through, in a sense, w…

Doesn't min_const_generics (stable once 1.51 releases on 2021-03-25) cover everything std needs (implementing traits for arbitrary array sizes)?

Re: GCC Rust: GCC Front-End for Rust

#160

Post by steveklabnik »

oconnor663 wrote: post #158
steveklabnik wrote: post #101

Earlier quoted context omitted.

Yes.

Oh that's impressive. I didn't know it was that far along.

It managed to do it for the first time Dec 24 2017 https://www.reddit.com/r/rust/comments/7lu6di/mrustc_alterna...

> It's managed to build rustc from a source tarball, and use that rustc as stage0 for a full bootstrap pass. Even better, from my two full attempts, the resultant stage3 files have been binary identical to the same source archive built with the downloaded stage0.

Post reply on HN