101–110 of 179 posts
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?)
Isn‘t mrustc already able to compile rustc?
Earlier quoted context omitted.
IMHO, "great deal" is overemphasizing it. There are some things, yes, but they are mostly smaller, more niche details that are even probably things we'd choose ourselves in many cases. That being said, there's also cases where Rust does not have LLVM semantics, and that can cause bugs. Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.
> Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias. I don't think that's a case where Rust "doesn't have LLVM semantics" since the miscompilation was reproduced in standard C. Rather that rust is actively and ubiquitously leveraging otherwise rarely-exercised LLVM features, revealing a bunch of bugs (either leftovers or breakages) in them.
So there is a significant difference in semantics between Rust and C/C++ here.
Earlier quoted context omitted.
> The former though is an area of significant divergence between Rust and C++ semantics, and LLVM blindly following C++ semantics. Ah I must have missed that, I thought you were talking about only one thing (since IIRC the noalias miscompilation is due to loop unrolling?)
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.)
loop {
core::sync::atomic::compiler_fence( core::sync::atomic::Ordering::SeqCst);
}
Earlier quoted context omitted.
> Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias. I don't think that's a case where Rust "doesn't have LLVM semantics" since the miscompilation was reproduced in standard C. Rather that rust is actively and ubiquitously leveraging otherwise rarely-exercised LLVM features, revealing a bunch of bugs (either leftovers or breakages) in them.
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.
I suspect it's too late, but one lesson that can be learned from D is that having one frontend implementation with multiple backend glue layers is much more convenient than having one in D and one in C++ (I believe Iain Buclaw is in the process of moving the D frontend in gcc to use the proper D one as it's been lagging behind)
There are pros to that approach, but also cons. The major con is that keeping the rustc frontend would make an existing Rust compiler be a requirement, and not having that makes bootstrapping easier, which is a major pro. This (among other things) was debated a lot .
A major con of not sharing is not having a backend at all. It's a lot of work to keep up with a moving target
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?
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.
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…
I know OpenBSD avoids rust because of the bootstrapping issue, but they also avoid LLVM because of a licensing issue.
Earlier quoted context omitted.
The latter, you're right, I did make a mistake here. I was thinking of it as "Rust doesn't just do whatever LLVM does, see, we have semantics and LLVM compiles them wrong, so this is an example of that" but I forgot that actually, we do specify "this follows what LLVM does" currently, and the miscompilation is just a plain bug. Extra embarrassing because IIRC I was the one who made the PR saying that. The former thou…
> The former though is an area of significant divergence between Rust and C++ semantics, and LLVM blindly following C++ semantics. Ah I must have missed that, I thought you were talking about only one thing (since IIRC the noalias miscompilation is due to loop unrolling?)
There is a major effort to revamp the `noalias`/`restrict` handling going on for a while now. It takes quite long because it is hard and complex and we want to get it right.
In case you are interested, here is the new design https://reviews.llvm.org/differential/changeset/?ref=2170825 here the overall code changes currently considered https://reviews.llvm.org/D69542 and here you can find information on our monthly LLVM Alias Analysis call https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL5...
from the readme : > The developers of the project are keen “Rustaceans” with a desire to give back to the Rust community and to learn what GCC is capable of when it comes to a modern language. So what's the answer right now ? How does GCC measures "against" rust ?
Given the amount of existing frontends for GCC, even if not included in the main branch, not sure what they imply as modern. Ada, D, Go, Modula-3, Modula-2, C++20