17 ms·
GCC Rust: GCC Front-End for Rust
- ognarb 6y agoThis is very cool, maybe this could push the rust community to have a formal specification and a stable ABI in the future.
- steveklabnik 6y agoThe work on a spec is already going as fast as it reasonably can be. A stable ABI is unclear.
- rectang 6y agoGlad you're going slow on the stable ABI and resisting the pressure to put out something half-baked. The C++ ABI is horribly fragile and complex. Unless the pitfalls of C++ can be avoided, making no ABI promises is better.
- tumdum_ 6y agoNo stable ABI makes distributing shared libraries harder :/
- steveklabnik 6y agoEverything is tradeoffs. Stable ABI can also lead to other issues, like performance problems. C++ is dealing with some of these right now, and there are some situations (very very micro benchmarks, to be clear) where Rust is faster than C++ due to ABI issues.
- pjmlp 6y agoThat affects mostly GCC and clang, other compiler vendors are more happy to break ABI between major releases, as long as they aren't forbidden by ISO C++ specification. I was already sharing templates and classes across DLLs in Windows 3.x compilers, and keep doing it with VC++ to this day. On Linux with Qt and Gtkmm projects, and on macOS/iOS with their system frameworks. Which is the biggest reason I cannot put up with cargo's model to compile every single project from scratch, after git clone. As we have lengthy discussed, while it might not be a priority right now, it is certainly an adoption block among some Ada, Delphi, Swift, Objective-C, C and C++ communities.
- chubot 6y agoIf 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_Issues_With_C%2B%2B https://community.kde.org/Policies/Binary_Compatibility_Issu... Yes, you have to do a lot of extra work. That's working as intended. It's sort of an oxymoron to expect to use every C++ or Rust feature in your user-facing ABI and have it be stable. They are incredibly rich languages, with drastically different notions of "function" than C has (let alone other constructs like data layout)
- steveklabnik 6y ago(There are mechanisms to do this, yes)
- IshKebab 6y agoYes you should do that now but only because Rust doesn't have a stable ABI. If/when it does then there's nothing wrong with distributing shared libraries using the Rust ABI, just like there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff. The C++ ABIs are pretty stable.
- chubot 6y agothere isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff That's the whole point of the KDE doc I linked. It's not a reasonable strategy to use unrestricted C++, just like it's not a reasonable strategy to use unrestricted Rust. You actually have to design an ABI, not just rely on the compiler to do it for you. I thought there was a GNOME doc too, but I couldn't find it. The point remains: there are lots of things in C++ that people who care about stability don't use at their ABI boundaries.
- nicoburns 6y agoThere's also the possibility of an opt-in stable ABI (using the `repr` mechanism). I personally really like the idea of there being an opt-in cross-language ABI at a higher level (or supporting more use cases) than the C ABI (which is quite limiting).
- Blikkentrekker 6y agoDoes it not already have them if the programmer elect for it by choosing `repr(C)`, or is there more to it than that?
- steveklabnik 6y agoYou are exposing an imprecision in the way that this is usually talked about, yes. If you are willing to use the C ABI, then you can use a combination of that repr and annotations on your functions and produce a shared object in Rust with a stable ABI. What people usually mean here is that Rust would have its own stable ABI, that you would get “for free,” without needing to do that work. (It’s never actually free of course... but that’s yet another detail that is usually papered over when people talk about this.)
- wiz21c 6y agofrom 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 ?
- bonzini 6y agoFront-end–independent optimizations are still slightly better in GCC than in LLVM.
- moonchild 6y agoI wouldn't say 'better'. Certainly, they're different. GCC does better in some ways, but worse in others. Somewhat notably, GCC doesn't do as good of a job at register allocation on some RISC architectures.
- pjmlp 6y agoGiven 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
- yorwba 6y agoThe timeline looks rather ambitious https://github.com/Rust-GCC/gccrs/milestones https://github.com/Rust-GCC/gccrs/milestones
- unanswered 6y agoIt also looks rather incomplete. Are they not planning on implementing borrowck? If chalk/polonius were ready and had a C API the roadmap would begin to make sense.
- Nullabillity 6y agoMakes sense to me. As mrustc[0] mentions, implementing validation in a secondary compiler is much less important, because you can always just run the reference implementation as a glorified linter in the meantime. [0]: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- unanswered 6y agoThat's what I don't get. I looked through the available documentation briefly and didn't see any mention that this is intended to be a `mrustc`; it really seems to want to be a `rustc`. I'm not aware of other GCC frontends being less than complete compilers for their respective languages, and while I think that "rust without borrowck" is an interesting point in design space (discriminated unions, generics, macros, traits, closures), "rust without borrowck" is not rust.
- bobthebuilders 6y agoYou can plug in the borrow checker after writing the base compiler, but you if you block waiting for the borrow checker you get nothing done.
- faitswulff 6y agoI'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?
- gumby 6y agoIt's not written in rust; gcc is written in c. There is no bootstrapping involved.
- faitswulff 6y agoDo gcc languages - even low level ones - remain written in c?
- guerby 6y agoThe GCC Ada frontend is written in Ada: https://gcc.gnu.org/wiki/GNAT https://gcc.gnu.org/wiki/GNAT There is also a port of the Ada frontend to LLVM backend: https://github.com/AdaCore/gnat-llvm https://github.com/AdaCore/gnat-llvm
- pjmlp 6y agoBesides the Ada example, GDC shares the D frontend, written in D, with other D implementations.
- Narishma 6y agoC++ but yes.
- NieDzejkob 6y agoGCC is no longer written in C, but in C++. They switched after GCC 4.7.
- saagarjha 6y ago
- vlovich123 6y agoWhat 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 to make GCC an official backend of the main frontend. That will defocus some progress that happens with LLVM (every feature has to be implemented on both backends) and can make dev lives hard (eg “oh this problem comes up with GCC so use the LLVM backend “). The value would be if the majority of bugs/features are in the shared frontend. This project though seems like a parallel implementation of Rust. That’s valuable for the community and inevitable as a part of successful growth. I don’t believe it’s beneficial to the community though if this grows beyond a toy, niche project.
- thesuperbigfrog 6y ago>> The only way to do this properly, if desirable, is to make GCC an official backend of the main frontend. That will defocus some progress that happens with LLVM (every feature has to be implemented on both backends) and can make dev lives hard (eg “oh this problem comes up with GCC so use the LLVM backend “) No. The correct way is to create a Rust language specification that describes what the correct behavior is. Then whether LLVM, GCC, or something else is used does not matter. There won't be one implementation with defacto behavior, there will be multiple implementations that follow the spec. This is the way mature languages work.
- not2b 6y agoIt doesn't even have to stop progress. C++ does a new rev of the standard every 3 years. Rust has editions, which is a similar but less rigorous concept, and which could be made more rigorous.
- thesuperbigfrog 6y agoExactly. The C++ standard (https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard) is the specification that describes what a compiler must do to implement a particular "version" of C++ (for example, C++ 20). Just as there is a C++ standard and multiple C++ compilers that implement the standard, there should be a Rust standard and multiple implementations. This is the way that mature languages work.
- dleslie 6y agoThis is excellent; there's embedded targets that LLVM doesn't officially support and GCC does.
- mhh__ 6y agoGCC is straight up faster in quite a few benchmarks (it's basically neck and neck in most benchmarks, and you should try both if it matters). GCC is also roughly even in compilation speed now https://www.phoronix.com/scan.php?page=news_item&px=GCC-Faster-Kernel-Builds-Clang https://www.phoronix.com/scan.php?page=news_item&px=GCC-Fast... LLVM is much easier to work with internally but GCC is a seriously good compiler even now.
- Blikkentrekker 6y agoIs a great deal of actual Rust behavior not fairly intimately tied to LLVM? As far as I know it leaks various LLVM details and much of the documentation about various functions documents them as being little more than a thin wrapper to various LLVM internals.
- chrisseaton 6y agoI'd find that very surprising and interesting - I can't imagine which semantics could leak from LLVM into a language specification. Can you give some examples?
- Blikkentrekker 6y agoFor instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction 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-alloc.html https://doc.rust-lang.org/nomicon/vec-alloc.html
- stouset 6y agoI 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.
- samb1729 6y agoLooking 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.
- anticensor 6y agoThey missed the opprtunity to name it as grust.
- codetrotter 6y agoGust of wind
- anticensor 6y agogrust, not gust
- codetrotter 6y agoI know. What I mean is that gust of wind would be even better.
- mhh__ 6y agoI 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)
- steveklabnik 6y agoThere 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.
- mhh__ 6y ago> The major con 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
- steveklabnik 6y agoYes, that is a theoretical problem, for sure. All choices have pros and cons.
- jeltz 6y agoThere is another project for implementing a GCC backend for Rust which instead uses the libgccjit API. https://github.com/antoyo/rustc_codegen_gcc https://github.com/antoyo/rustc_codegen_gcc
- ibraheemdev 6y agoThere 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 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 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-independent-rust-frontend-for-gcc/32163 https://users.rust-lang.org/t/call-for-help-implementing-an-...
- deleted 6y ago[deleted]
- ncmncm 6y agoIt would be a grave error to have coded the Rust frontend to Gcc in C (or, as written above, "in c"). Gcc is now a C++ codebase, and new components should be coded in modern C++, for better productivity, performance, safety, and maintainability. (You might prefer not to consider modern C++ more productive, performant, safe, and maintainable than C (and reflexively downvote), but the statement remains true: Gcc did transition to C++, for reasons. And, all the improvements that have kept Gcc competitive with Clang were done, since. And, Clang and LLVM are also coded in C++, also for reasons.)
- Ericson2314 6y agoA bit off topic, I hope someday GCC's build system gets overhauled. A huge advantage of LLVM is that it is quite easier to rebuild the runtime libraries without rebuilding the compiler. With GCC that's a pain, unless one takes the time to re-package GCC very carefully like https://github.com/richfelker/musl-cross-make https://github.com/richfelker/musl-cross-make and https://exherbo.org/ https://exherbo.org/. Maybe getting some new GCC devs in there with projects like this would help with that?
- potatochup 6y agoDoes this mean that compilation target currently supported by GCC would now allow rust to target that architecture? Specifically I'm thinking of PPC cores with the VLE extension, which LLVM does not support (as far as I'm aware).
- volta87 6y agollvm does support ppc64le cores with VSX extension; if thats what you mean in fact, IBM uses LLVM proper as its own compiler backend for its ppc processors
- potatochup 6y agoThe VLE I'm talking about is this: https://www.st.com/resource/en/user_manual/cd00161395-variable-length-encoding-vle-extension-programming-interface-manual-stmicroelectronics.pdf https://www.st.com/resource/en/user_manual/cd00161395-variab... This may be a vendor-specific extension though?
- BlackFingolfin 6y agoSorry for the nitpick, but I find the title rather confusing; shouldn't it rather be "Rust front-end for GCC"?
- pirocks 6y agoYou could make the argument that, that would be a frontend written in rust.
- piinbinary 6y agoDon'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.
- tele_ski 6y agodid 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!
- piinbinary 6y agoI incorrectly assumed that `-j` and `-j$(nproc)` would do the same thing. TIL!
- jjnoakes 6y agoEcstatic to see this. Once this stabilizes then I can switch my shop to rust and not look back. If I find some spare time I will absolutely try to find a way to contribute.
- kzrdude 6y agoDo you mean that you will use this, or just have the alt implementation as a checkbox item? Because - I'm just guessing of course - for this to be a mature alternative compiler we might be looking at 5, 10 years in the future, or never. Just being realistic, things take time to grow (and it's also uncertain how they can ever be able to keep pace with the rapidly developing Rust project). With all this said, I would love for them to succeed, for multiple reasons. Including <3 GPL.
- jjnoakes 6y agoI mean that I'd use it. If it takes a while then maybe I can get by with mrustc for a bit (haven't tried yet) but the net of it is that I need to support systems which llvm does not, which has kept me from using rust in product thus far.
- stevefan1999 6y agoThis is the very first step to getting Rust into Linux kernel. I liked that.
- steveklabnik 6y agoIt is not required for getting Rust into Linux.