Announcement

Collapse
No announcement yet.

GCC Rust Front-End Continues Advancing With Plans To Eventually Upstream

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC Rust Front-End Continues Advancing With Plans To Eventually Upstream

    Phoronix: GCC Rust Front-End Continues Advancing With Plans To Eventually Upstream

    While the official/reference Rust compiler implementation is LLVM-based, there continues to be the independent effort working on a GCC Rust front-end as an alternative full implementation of the Rust programming language...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Watching this closely. The main reason I've been hesitant to start any important projects in Rust is the fact that its so closely tied to LLVM with no alternative implementation. A GCC frontend will be a huge win.

    Comment


    • #3
      Now the things will get more complicated with two compiler implementations and no formal language specification. I guess it's good news anyhow, given that it should push language towards maturity.

      Comment


      • #4
        Originally posted by clavko View Post
        Now the things will get more complicated with two compiler implementations and no formal language specification. I guess it's good news anyhow, given that it should push language towards maturity.
        And they can verify each other to clear out any ambiguous statements.

        Comment


        • #5
          Originally posted by hipower View Post
          Watching this closely. The main reason I've been hesitant to start any important projects in Rust is the fact that its so closely tied to LLVM with no alternative implementation. A GCC frontend will be a huge win.
          Frontend fragmentation is absolutely no win, it's a straight way to the same hell situation we have with C and C++: a lot of implementations with their own quirks, bugs and deviations from the standard. Linux kernel for example is not written in C, it's written pretty much in GCC and can barely (or not at all) be compiled with anything else.
          As a Rust developer the last thing I want is "alternate" frontends with lacking features, incomplete implementations and the whole set of libraries which only work with one compiler but not with the other.

          The much better approach to my opinion is: https://github.com/antoyo/rustc_codegen_gcc
          The frontend remains only one. And it should be only one. The backend can be GCC with an access to all architectures it supports.

          P.S. Bootstrapping trust could be an issue though for the purists who build their toolchains from the hand-written assembly. I'd rather go with a pragmatic approach.
          Last edited by dremon_nl; 29 May 2021, 02:48 PM.

          Comment


          • #6
            I'm not particularly excited by this. Alternate implementations were essential when compilers or even the languages themselves were proprietary, with Rust being fully FOSS that's kind of moot.

            Comment


            • #7
              Originally posted by dremon_nl View Post

              Frontend fragmentation is absolutely no win, it's a straight way to the same hell situation we have with C and C++: a lot of implementations with their own quirks, bugs and deviations from the standard. Linux kernel for example is not written in C, it's written pretty much in GCC and can barely (or not at all) be compiled with anything else.
              As a Rust developer the last thing I want is "alternate" frontends with lacking features, incomplete implementations and the whole set of libraries which only work with one compiler but not with the other.

              The much better approach to my opinion is: https://github.com/antoyo/rustc_codegen_gcc
              The frontend remains only one. And it should be only one. The backend can be GCC with an access to all architectures it supports.

              P.S. Bootstrapping trust could be an issue though for the purists who build their toolchains from the hand-written assembly. I'd rather go with a pragmatic approach.
              My kernels are working great compiled with Clang, LLD with thin-LTO

              Comment


              • #8
                Originally posted by FireBurn View Post

                My kernels are working great compiled with Clang, LLD with thin-LTO
                I know you probably remember the hundreds of patch to allow it to happen since kernel 4 dot something

                Comment


                • #9
                  Originally posted by dremon_nl View Post

                  Frontend fragmentation is absolutely no win, it's a straight way to the same hell situation we have with C and C++: a lot of implementations with their own quirks, bugs and deviations from the standard. Linux kernel for example is not written in C, it's written pretty much in GCC and can barely (or not at all) be compiled with anything else.
                  As a Rust developer the last thing I want is "alternate" frontends with lacking features, incomplete implementations and the whole set of libraries which only work with one compiler but not with the other.

                  The much better approach to my opinion is: https://github.com/antoyo/rustc_codegen_gcc
                  The frontend remains only one. And it should be only one. The backend can be GCC with an access to all architectures it supports.

                  P.S. Bootstrapping trust could be an issue though for the purists who build their toolchains from the hand-written assembly. I'd rather go with a pragmatic approach.
                  Agreed. The last thing I want for Rust is to end up like the dlang community with at least three compilers that are all incomplete but in different ways.

                  Comment


                  • #10
                    On the other hand, if Rust does start being used in the kernel, especially eventually for something non-trivial or entirely isolated, then the situation will be reversed since there will be parts of the kernel that can only be able to be compiled with LLVM. If Rust is going to ever be used in the kernel outside of small, self-contained areas, I would assume that would be a non-starter.
                    Last edited by Pentarctagon; 29 May 2021, 09:53 PM.

                    Comment

                    Working...
                    X