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

161–170 of 179 posts

Re: GCC Rust: GCC Front-End for Rust

#161

Post by steveklabnik »

CodesInChaos wrote: post #159
steveklabnik wrote: post #35

Earlier quoted context omitted.

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

I believe that it does, yes. We haven't hit that in stable yet, though, so I am speaking purely in the present. You're right that it's looking good for stabilization in a few months, but anything can happen, in theory. I'm more trying to illustrate the point, that significant features can depend on something that's unstable currently. Those impls landed well before it was even marked as being stable in nightly.

Re: GCC Rust: GCC Front-End for Rust

#162

Post by piinbinary »

tele_ski wrote: post #125
piinbinary wrote: post #120

Don't try to compile this with `make -j` - I tried, and my system ran out of ram and swap and started OOM killing things. I have 16 threads and 32gb of ram. Running `make -j4` seems safe thus far.

did you try make -j16 since you have 16 cores? -j with no number means spawn as many parallel jobs as possible which could be hundreds or thousands depending on the project, I learned this the hard way a while ago myself when I used $(nproc) incorrectly on a project, got the same OOM/swapping death spiral!

I incorrectly assumed that `-j` and `-j$(nproc)` would do the same thing. TIL!

Re: GCC Rust: GCC Front-End for Rust

#163

Post by Dylan16807 »

volta87 wrote: post #146
Dylan16807 wrote: post #130

Earlier quoted context omitted.

Loops that do nothing and don't terminate. If your loop infinitely writes the number 70 to an atomic int, it's fine.

If by "nothing" you mean "nothing but looping", then yes, you are right. Any loop that "just loops" is doing something by definition: looping.

It depends on your perspective. Normally when I talk about what a loop "does", I am talking purely about the contents of the loop.

Re: GCC Rust: GCC Front-End for Rust

#164

Post by moltonel3x »

singron wrote: post #7
faitswulff wrote: post #5

I'm not sure if what I'm asking makes sense, but since it's written for a new backend, would the authors have to bootstrap it using a different toolchain? I guess what I'm asking is, could they use the LLVM Rust to build the GCC frontend or do they have to start all over with a different base language to get a first working version of a rust compiler?

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.

Looking forward to the day when gcc gains a C++ frontend written in Rust, to enable bootstraping gcc from a rust compiler :)

Re: GCC Rust: GCC Front-End for Rust

#165

Post by moltonel3x »

zabzonk wrote: post #93
steveklabnik wrote: post #88

Earlier quoted context omitted.

There are more languages that have standards, sure, but the languages you mention, at this point, and in general, are mostly relegated to historical maintenance and maybe some very specific niches. To me personally, a “mature” language that’s not really being used isn’t the goal. And if developers truly believed standardization was valuable, you’d expect this property to give them a significant leg up against the sor…

Well, I agree that standardisation and "maturity" (whatever that may mean) are not connected, but I think most C and C++ programmers (to name two very widely used languages that I personally have a lot of knowledge of) find the respective standards for those languages very helpful, and somewhat lament the lack of formal standards for other languages they may use.

The C and C++ specs are full of UB though, more like a "minimum common denominator" for compiler devs than a strict spec that users can rely on. It's way too easy to write spec-abiding code that behaves differently with different compilers/architectures/optimizations.

Specs are definitely a good thing to have, but often they're just brandished as a bullet point without looking at the details: how good is the spec, what does it add over the existing tests/CI/RFCs/proofs, etc.

Re: GCC Rust: GCC Front-End for Rust

#166

Post by chubot »

gpderetta wrote: post #153
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…

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…

That's fair, there is a middle ground between C and C++. My point is that you can't expect the compiler to do everything for you in terms of creating a stable ABI for shared libraries. I think a lot of people are under the impression that this is purely a compiler feature.

What I expect to happen is that rather than "Rust gets a stable ABI" it will be "Rust very gradually builds upon the C ABI for selected features".

Most C++ libraries have templates in their signatures these days for efficiency, and Rust has a similar flavor (monomorphization). I think there is a fundamental tradeoff there between stability and performance, and both languages have a heavy emphasis on the latter. I could be missing something as I certainly don't know all the details of the C++ ABI.

Re: GCC Rust: GCC Front-End for Rust

#167

Post by gpderetta »

chubot wrote: post #166
gpderetta wrote: post #153

Earlier quoted context omitted.

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…

That's fair, there is a middle ground between C and C++. My point is that you can't expect the compiler to do everything for you in terms of creating a stable ABI for shared libraries. I think a lot of people are under the impression that this is purely a compiler feature. What I expect to happen is that rather than "Rust gets a stable ABI" it will be "Rust very gradually builds upon the C ABI for selected features".…

Even with templates you can still keep the ABI stable, se for example libstdc++. Which is not surprising as they compile down to the equivalent C code.

Re: GCC Rust: GCC Front-End for Rust

#168

Post by chubot »

gpderetta wrote: post #167
chubot wrote: post #166

Earlier quoted context omitted.

That's fair, there is a middle ground between C and C++. My point is that you can't expect the compiler to do everything for you in terms of creating a stable ABI for shared libraries. I think a lot of people are under the impression that this is purely a compiler feature. What I expect to happen is that rather than "Rust gets a stable ABI" it will be "Rust very gradually builds upon the C ABI for selected features".…

Even with templates you can still keep the ABI stable, se for example libstdc++. Which is not surprising as they compile down to the equivalent C code.

I think your example is better evidence for my view. I remember this issue being mentioned in a CppCon talk: C++ 11 broke the ABI for STL (for efficiency as far as I remember), and the binary interface to libstdc++ changed as a result:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...

So the ABI can leak implementation details in nontrivial ways that library authors usually don't consider. It's better to have something explicit in the code, e.g. under extern "C".

The point is not that making a stable API for every language feature is impossible; just that it's hard, fragile, and maybe not be worth the effort. If you really want stability, then use fewer features more like C. There is probably some middle ground that's richer, but templates are known to cause problems.

Also see the release history here:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Re: GCC Rust: GCC Front-End for Rust

#169

Post by pabs3 »

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…

The Bootstrappable builds folks dislike binary artifacts so much they are implementing bootstrapping a full Linux system from only 512 bytes of machine code plus all the source code:

https://bootstrappable.org/ https://bootstrapping.miraheze.org/wiki/Main_Page

Re: GCC Rust: GCC Front-End for Rust

#170

Post by eru »

anfilt wrote: post #137
eru wrote: post #135

Earlier quoted context omitted.

> If I was choosing a compiled language for system development right now I would choose C or Rust. I'm not quite sure what systems development has to do with compiler writing? (I assume by system development, you mean something like writing OS kernels etc?) Eg there are good reasons to stay away from automatic memory management when you are writing an OS, you want control over that. But those reasons hardly apply whe…

System programs can be in user space for instance a run time for another language. As for a compiler ideally its easy to port as its kinda of the bed rock to get any other system going. Although a compiler for some architecture or use cases is too large to be self hosted or does not make sense to be self hosted. So its not always a deal breaker for a compiler.

> System programs can be in user space for instance a run time for another language.

OK, I can live with that definition.

But what does it have to do with the language you write your compiler in?

Post reply on HN