They missed the opprtunity to name it as grust.
GCC Rust: GCC Front-End for Rust
41–50 of 179 posts
Re: GCC Rust: GCC Front-End for Rust
#42Earlier quoted context omitted.
For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction I'm not sure as to what capacity GCC has a similar instruction but I heard that LLVM 's using of signed integers here is apparently nonstandard and what lead to Rust 's decisions for vectors to be limited to a certain size: https://doc.rust-lang.org/nomicon/vec-…
I don’t know why you’re italicizing LLVM, gcc, and Rust, but I (and perhaps others) find it relatively jarring as my brain automatically parses it as emphasis even though it clearly isn’t intended to be. I only bring it up because it pretty drastically harms readability (for me at least, and to a degree I frankly find surprising). Just thought you may want to know.
Looking at their commenting history, they have a habit of italicising really often, so it's not specific to this topic. It does indeed make a lot of their comments annoying to read without obviously adding any value.
Re: GCC Rust: GCC Front-End for Rust
#43Earlier quoted context omitted.
For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction I'm not sure as to what capacity GCC has a similar instruction but I heard that LLVM 's using of signed integers here is apparently nonstandard and what lead to Rust 's decisions for vectors to be limited to a certain size: https://doc.rust-lang.org/nomicon/vec-…
I don’t know why you’re italicizing LLVM, gcc, and Rust, but I (and perhaps others) find it relatively jarring as my brain automatically parses it as emphasis even though it clearly isn’t intended to be. I only bring it up because it pretty drastically harms readability (for me at least, and to a degree I frankly find surprising). Just thought you may want to know.
This is common nomenclature to enhance readability in fields that have a large number of neologisms and proper nouns, such as some technical domains, medicine, investment banking, and so on. It's particularly useful when names are in the same language as the base language (e.g. in English "Peter" is easily recognized as a name, but "better fish" means something in the language, but can also be used as a proper noun, so using italics for proper nouns serves to disambiguate the intended meaning).
Re: GCC Rust: GCC Front-End for Rust
#44Earlier 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.
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 though is an area of significant divergence between Rust and C++ semantics, and LLVM directly following C++ semantics.
Re: GCC Rust: GCC Front-End for Rust
#45I 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)
Re: GCC Rust: GCC Front-End for Rust
#46Earlier quoted context omitted.
There is absolutely no reason why the GCC front-end needs to be written in Rust. The reason the LLVM front-end was written in Rust initially was so they could immediately test and use new features in what was at the time also the largest program in Rust. Re-writing the GCC front-end in Rust would just prolong an already rather unfortunate bootstrap problem with the language and it should be strongly discouraged. As i…
> 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.
Re: GCC Rust: GCC Front-End for Rust
#47Earlier quoted context omitted.
For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction I'm not sure as to what capacity GCC has a similar instruction but I heard that LLVM 's using of signed integers here is apparently nonstandard and what lead to Rust 's decisions for vectors to be limited to a certain size: https://doc.rust-lang.org/nomicon/vec-…
getelementptr is just some pointer arithmetic - all backends can do that. And using signed integers is unusual yes, but again all backends (obviously) also support signed integers.
IMHO, "Just some pointer arithmetic" is selling it a bit short. There's a lot of stuff there around provenance that matters, that is, there's a reason this is an intrinsic and not just a subtraction after casting both to an int.
(I agree on the signed integer thing though.)
Re: GCC Rust: GCC Front-End for Rust
#48from 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 ?
Front-end–independent optimizations are still slightly better in GCC than in LLVM.
Re: GCC Rust: GCC Front-End for Rust
#49I 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.
Re: GCC Rust: GCC Front-End for Rust
#50Earlier quoted context omitted.
I see, so it’s written in C++. Would it remain that way, though? AFAIK the LLVM Rust is, itself, written in Rust, right? I imagine that it would be a goal to do the same for gcc.
There is absolutely no reason why the GCC front-end needs to be written in Rust. The reason the LLVM front-end was written in Rust initially was so they could immediately test and use new features in what was at the time also the largest program in Rust. Re-writing the GCC front-end in Rust would just prolong an already rather unfortunate bootstrap problem with the language and it should be strongly discouraged. As i…
I don't see why a wasm blob would be any more palatable to maintainers than an executable.