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

61–70 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#61

Post by pm215 »

bonzini wrote: post #46
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?

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

Re: GCC Rust: GCC Front-End for Rust

#62

Post by pjmlp »

faitswulff wrote: post #9
gumby wrote: post #6

Earlier quoted context omitted.

It's not written in rust; gcc is written in c. There is no bootstrapping involved.

Do gcc languages - even low level ones - remain written in c?

Besides the Ada example, GDC shares the D frontend, written in D, with other D implementations.

Re: GCC Rust: GCC Front-End for Rust

#63

Post by pjmlp »

wiz21c wrote: post #3

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

Re: GCC Rust: GCC Front-End for Rust

#64

Post by Blikkentrekker »

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.

This is indeed a point of contention among different styles of whether software titles should be italicized. Though the position that they should uniformly be is the minority one, it is certainly used by some outlets with considerable weight, and I believe it to be the consistent one if titles of books and films are too.

Some style guides make the even more inconsistent distinction that only titles of video games be italicized, but titles of “application software” not be.

I suppose that on H.N., where such software is frequently mentioned, it does stand out more.

Re: GCC Rust: GCC Front-End for Rust

#65

Post by codetrotter »

samb1729 wrote: post #42
stouset wrote: post #32

Earlier quoted context omitted.

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.

> It does indeed make a lot of their comments annoying to read without obviously adding any value

I’m going to assume that you mean that the italics don’t add value, and not their comments as a whole. I think your comment could be read either way. Anyways, even so others have since pointed out reasons why the might be used to doing so.

Re: GCC Rust: GCC Front-End for Rust

#67

Post by ibraheemdev »

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 specs require multiple independent implementations (so just attaching GCC as a new backend for rustc wouldn't work).

Luke:

> The goal is for the GNU Compiler Collection to have a peer level front end to the gfortran frontend, gcc frontend, g++ frontend and all other frontends.

> The goal is definitely not to have a compiler written in rust that compiles rust code [edit: unless there is an acceptable bootstrap process, and the final compiler produces GNU assembly output that compiles with GNU gas]

> The goal is definitely not to have a hard critical dependence on LLVM.

> The goal is to have code added, written in c, to the GNU Compiler Collection, which may be found here https://gcc.gnu.org 20 such that developers who are used to gcc may compile rust programs and link them against object files using binutils ld.

> The primary reason why I raised this topic is because of an experiment permitting rust modules to be added to the linux kernel: https://lwn.net/Articles/797828

> What that effectively means if that takes off is that the GNU Compiler Collection, which would be incapable of compiling that code, would be relegated to a second class citizen for the purposes of compiling the largest software project on the planet: the linux kernel.

> Thus it is absolutely critical that GCC be capable not just of having rust capability but of having up to date rust capability.

0: https://users.rust-lang.org/t/call-for-help-implementing-an-...

Re: GCC Rust: GCC Front-End for Rust

#68

Post by steveklabnik »

masklinn wrote: post #52
steveklabnik wrote: post #44

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

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

Re: GCC Rust: GCC Front-End for Rust

#69

Post by pjmlp »

simias wrote: post #58
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 St…

Yeah, when one forgets that there are more C and C++ compilers out there in the industry than just the pair that the FOSS community cares about.

Re: GCC Rust: GCC Front-End for Rust

#70

Post by pjmlp »

jcelerier wrote: post #55
not2b wrote: post #30

Earlier quoted context omitted.

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.

Compilation speed isn't one of them though.
Post reply on HN