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

51–60 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#51

Post by turminal »

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…

Having multiple independent implementations (and a spec) is key to being a serious portable systems language, a claim that Rust already makes. I believe it's too early for that, but sincerely wish them success achieving those goals in the future and having multiple implementations is certainly going to help here.

> eg “oh this problem comes up with GCC so use the LLVM backend “

The point of having multiple implementations is making the language independent of the underlying system. A programming language is an abstraction. The only way to test whether an abstraction is a good one is trying out how well it abstracts away various underlying systems. That's why Rust needs ports to various architectures, OSes and compiler backends. Having GCC as a backend counts double here, because you get a few new target architectures for free with the port not just a new backend.

It's of course much different with Python but I can still clearly see how having an implementation defining a standard hurts the language.

Re: GCC Rust: GCC Front-End for Rust

#52

Post by masklinn »

steveklabnik wrote: post #44
masklinn wrote: post #40

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.

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

Re: GCC Rust: GCC Front-End for Rust

#53

Post by Guvante »

varajelle wrote: post #22
strongdenial wrote: post #11

Earlier 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?

No one is saying that rustc should be rewritten in C. They are saying that an alternative compiler front-end in an alternative language is sensible.

Re: GCC Rust: GCC Front-End for Rust

#55

Post by jcelerier »

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…

> C++ has benefited hugely by the competition between g++ and clang; both compilers have gotten much, much better.

yet rust has a single implementation and by some metrics does better than both.

Re: GCC Rust: GCC Front-End for Rust

#56

Post by tssva »

stouset wrote: post #32
Blikkentrekker wrote: post #29

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

Maybe he is used to writing in MLA style which calls for the titles of software to be italicized just as books, movies, etc are.

Re: GCC Rust: GCC Front-End for Rust

#57

Post by turminal »

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…

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

Re: GCC Rust: GCC Front-End for Rust

#58

Post by simias »

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…

Remember that Rust is supposed to be an alternative to C or C++, where the "this problem comes up with GCC so use the LLVM backend" is really rare and generally a sign of a bad codebase (exceptions being things like the Linux kernel that are so huge, optimized and domain-specific that they often end up relying on compiler dialects).

One exception to this is Visual Studio's toolchain but let's not talk about Visual Studio's toolchain on a weekend...

Re: GCC Rust: GCC Front-End for Rust

#59

Post by strongdenial »

Null-Set wrote: post #50
strongdenial wrote: post #11

Earlier 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…

I don't see why a wasm blob would be any more palatable to maintainers than an executable.

Like I mentioned in my post, it wouldn't be for some depending how serious they take things. I'm well aware many would refuse generated artifacts, even compiled to source artifacts. For others not so strict, they may accept it since the WASM blob would be the same across targets, unlike an executable, so it lessens a burden as maintainers only have to generate it once for their distribution. It was never something I suggested the Rust maintainers provide a blob for, either.

Regardless, it was worth mentioning as a potential option. I am one of the handful of maintainers for an experimental distribution where packages are either compiled or interpreted from tarballs and this would be something we'd consider. I'd MUCH rather have the GCC front-end option, however. So far, we've simply not packaged Rust and have accepted that as dead-ending our Firefox package. This may potentially revive it.

Re: GCC Rust: GCC Front-End for Rust

#60

Post by pjmlp »

faitswulff wrote: post #8
singron wrote: post #7

Earlier quoted context omitted.

As far as I can tell, this is written in C++ like the rest of GCC, so they don't need a rust compiler to bootstrap.

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.

It could take the same approach as GDC and GNAT, by having the frontend written on the same language (D and Ada respectively), shared with other implementations using another set of backends.
Post reply on HN