9 ms·

GCC 13 and the State of Gccrs

154 points by jmillikin 4y ago

amir734jj 3y ago
I would imagine this is a massive effort. Rust is not a simple language
Georgelemental 3y ago
gcc-rs is one of two projects for bringing Rust to gcc. gcc-rs is the more ambitious of the two, with an entirely new frontend. There is also rustc_codegen_gcc (https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc) that keeps the rustc frontend, and only swaps out LLVM for GCC at the codegen stage.
- mercurial 3y ago
  IMO, rustc_codegen_gcc is much more reasonable in scope. It also stands a chance of actually keeping up with subsequent Rust releases. I would be surprised if gcc-rs ever achieved any traction. Not to say it's not a fun project, but I can't see it replicating rustc.
  - e3bc54b2 3y ago
    It doesn't has to match rustc on nightly, only the 3-yearly releases. That seems doable, considering Rust has slowed down a bit, compared to super fast pace of change in early years. Regardless, it is always good to have alternate implementations, C++ has only benefited from it.
    - tialaramex 3y ago
      I'm guessing you aren't a Rust programmer? By "3-year releases" you're probably meaning Editions, but Rust Editions aren't like the C++ Standard, where they're bundling together a bunch of new features† the Edition changes language syntax, usually in small ways. The features people care about are released every six weeks and aren't saved up for new Editions. For example, 1.69 released last week, so now: SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 8080) ... is a constant, at compile time the data structure equivalent to 127.0.0.1:8080 is constructed and baked into your binary program. If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. If an alternative compiler doesn't have the features of Rust 1.69, then code written for Rust 1.69 won't necessarily work with it. Sometimes such differences will be tiny, other times huge. † And notice that just because say, Modules was a C++ 20 feature, did not mean that you woke up one day in 2020 and had working Modules, C++ 20 is just an ISO document, the features have to get implemented by vendors, and then tested, and then shipped, which can take weeks, or months, or years.
      - proto_lambda 3y ago
        Bad example because that's a library feature and doesn't involve explicit compiler support - in general you're right though, backwards-compatible compiler features (say, GATs) are added regularly and are available for all editions, not just the newest one.
        epage 3y ago
        Except the library uses nightly features so to pull in newer versions, you have to be up to date with all the unstable compiler features.
      - Karellen 3y ago
        Not parent, but not a rust programmer: > If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. How would it not work? If your program compiles and runs with 1.69, then surely that's because it never tries to modify the value. But if your program never tries to modify the value, how would it fail with 1.68?
        estebank 3y ago
        The GP is missing a small bit of context: because this construct is now const, it can be used in const contexts, like to initialize a static variable. Doing so didn't work in 1.68, but does now in 1.69.
        phkahler 3y ago
        But older code will still work with the new compiler right?
        mkj 3y ago
        Yes
        estebank 3y ago
j16sdiz 3y ago
I don't think this can end well. Rust have too many underspecified behavior, and the only source of truth is the official implementation. Everybody know the type system in rust is NP-complete. The compiler use different heuristics and hints to do a best effort solution. I can't imagine how this can be reimplemented
- sanxiyn 3y ago
  I note that Rust already has been reimplemented (mrustc), mostly by one person.
  - j16sdiz 3y ago
    mrustc assume all rust code is valid and skips all those heuristics checks. gccrs on the other hand, aims to be a full implementation with all those checkers.
    - 3836293648 3y ago
      Gccrs does not aim to be a full implementation. They're aiming to be a good enough implementation that they can steal the last parts (the borrow checker) from rustc. More specifically they're aiming to steal the next gen borrow checker, not the current one
- jmillikin 3y ago
  GCC is first and foremost a compiler for GNU C, which is a set of unspecified extensions to C, which is a language that achieved near-universal adoption despite decades of competing mutually-incompatible implementations. C++ templates are Turing-complete, and GCC implements them just fine. The idea that Rust requires a formal specification (outside very rare situations, like aeronautic firmware) is silly.
  - Vogtinator 3y ago
    You forgot the </sarcasm> tag. Or are you actually serious with your comment? GCC supports various "flavors" of C, including fully standard compliant versions. GNU extensions are all documented.
alkonaut 3y ago
Why is it necessary to do this? I get that having multiple implementations of a language is a good thing. But why does GCC in particular want to do it, and why with two separate efforts of different levels of ambition? Is it related to rust-in-kernel efforts? What stops using the normal rustc for that?
- flohofwoe 3y ago
  Because competition and choice is good? Even though having to support multiple C/C++ compilers can be painful at times for programmers, the competition between GCC, Clang and MSVC is definitely a good thing (imagine being stuck with MSVC on Windows when MSVC was about 15 years behind the C standard until recently). A separate Rust compiler may also uncover problems in the language or standard library design (e.g. if it's too much effort to write a Rust compiler from scratch that definitely isn't a good thing IMHO).
  - alkonaut 3y ago
    Yes that much I got. It's a thing that would be nice to have. But that doesn't explain exactly why the GCC would be the ones doing it nor why there would be two separate projects.
    - bayindirh 3y ago
      Because having a Free implementation which complements the Open Source one is a great way to keep the language alive, evolve it in a saner way, and improve ways we thought it's impossible to do. clang made gcc and g++ better compilers. gcc-rs can do the same and help making rustc a better compiler and Rust a better language. For the record, I don't write Rust, because GCC has no Rust support yet. More specifically, I don't use LLVM-Specific languages due to LLVM's license and stance against GCC.
      - estebank 3y ago
        How is Rust not evolving in a sane way today?
wiz21c 3y ago
I'd like to point out the quality of the blog post. It is extremely well written. For me it gives a very good sign about where all of this is going.
fithisux 3y ago
Until, then, gdc (gcc dlang) can serve you today.
- Shish2k 3y ago
  gdc can compile my rust code to obscure embedded targets?
KingLancelot 3y ago
[dead]
philberty 3y ago
The biggest problem Rust has is that "no_core" is so poorly understood at this point that i doubt a comprehensive spec is even possible to explain: 1. Type inference taking into account higher ranked trait bounds - Slices in libcore work via the Index lang item so its like taking an index operator overload to a range lang item but the generic types in the range need to be unified with the higher ranked trait bound to eventually figure out that they are meant to be of usize. 2. Method resolution its almost a joke at this point how complicated it is in Rust. - The autoderef cycle sounds simple when you read this: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/deref-coercions.html - But this misses so much extra context information 3. Macro invocations there are really subtle rules on how you treat macro invocations such as this which is not documented at all https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/expand/rust-macro-expand.cc#L1010-L1017 https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/expan... </rant> Some day I personally want to write a blog post about how complicated and under spec'd Rust is, then write one about the stuff i do like it such as iterators being part of libcore so i don't need reactive extensions.
- ChrisSD 3y ago
  Hm... I'm not sure I understand. Why would you expect no_core to be specified? It's an implementation detail of rustc, not part of the language.
  - philberty 3y ago
    No core _is_ the Rust language, libcore is just a library which adds the "Rust abstractions" so you can actually write a for loop or create a slice or deref, add or anything else. Libcore just gets compiled like any other rust crate just it does not have access to abstractions. For example, you can still write C code without libc because C is a language libc is just a library libcore is pretty much the same. Though Rust makes alot of assumptions that libcore _should_ be there but its possible for it not to be.
    - ChrisSD 3y ago
      core is part of the language (or at least, many parts of it are). The way that rustc currently splits this up is an implementation detail of rustc, not something that must be copied exactly. Rust without core is not Rust. It's not even usable.

154 points by jmillikin 4y ago

I would imagine this is a massive effort. Rust is not a simple language

gcc-rs is one of two projects for bringing Rust to gcc. gcc-rs is the more ambitious of the two, with an entirely new frontend. There is also rustc_codegen_gcc (https://github.com/rust-lang/rustc_codegen_gcc https://github.com/rust-lang/rustc_codegen_gcc) that keeps the rustc frontend, and only swaps out LLVM for GCC at the codegen stage.

mercurial 3y ago
IMO, rustc_codegen_gcc is much more reasonable in scope. It also stands a chance of actually keeping up with subsequent Rust releases. I would be surprised if gcc-rs ever achieved any traction. Not to say it's not a fun project, but I can't see it replicating rustc.
- e3bc54b2 3y ago
  It doesn't has to match rustc on nightly, only the 3-yearly releases. That seems doable, considering Rust has slowed down a bit, compared to super fast pace of change in early years. Regardless, it is always good to have alternate implementations, C++ has only benefited from it.
  - tialaramex 3y ago
    I'm guessing you aren't a Rust programmer? By "3-year releases" you're probably meaning Editions, but Rust Editions aren't like the C++ Standard, where they're bundling together a bunch of new features† the Edition changes language syntax, usually in small ways. The features people care about are released every six weeks and aren't saved up for new Editions. For example, 1.69 released last week, so now: SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 8080) ... is a constant, at compile time the data structure equivalent to 127.0.0.1:8080 is constructed and baked into your binary program. If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. If an alternative compiler doesn't have the features of Rust 1.69, then code written for Rust 1.69 won't necessarily work with it. Sometimes such differences will be tiny, other times huge. † And notice that just because say, Modules was a C++ 20 feature, did not mean that you woke up one day in 2020 and had working Modules, C++ 20 is just an ISO document, the features have to get implemented by vendors, and then tested, and then shipped, which can take weeks, or months, or years.
    - proto_lambda 3y ago
      Bad example because that's a library feature and doesn't involve explicit compiler support - in general you're right though, backwards-compatible compiler features (say, GATs) are added regularly and are available for all editions, not just the newest one.
      - epage 3y ago
        Except the library uses nightly features so to pull in newer versions, you have to be up to date with all the unstable compiler features.
    - Karellen 3y ago
      Not parent, but not a rust programmer: > If I write a Rust program which relies on this for a constant, it works fine, because it is constant, but if I try to compile it with Rust 1.68 (from earlier this year) it won't work. How would it not work? If your program compiles and runs with 1.69, then surely that's because it never tries to modify the value. But if your program never tries to modify the value, how would it fail with 1.68?
      - estebank 3y ago
        The GP is missing a small bit of context: because this construct is now const, it can be used in const contexts, like to initialize a static variable. Doing so didn't work in 1.68, but does now in 1.69.
        phkahler 3y ago
        But older code will still work with the new compiler right?
        mkj 3y ago
        Yes
        estebank 3y ago

j16sdiz 3y ago

I don't think this can end well. Rust have too many underspecified behavior, and the only source of truth is the official implementation. Everybody know the type system in rust is NP-complete. The compiler use different heuristics and hints to do a best effort solution. I can't imagine how this can be reimplemented

sanxiyn 3y ago
I note that Rust already has been reimplemented (mrustc), mostly by one person.
- j16sdiz 3y ago
  mrustc assume all rust code is valid and skips all those heuristics checks. gccrs on the other hand, aims to be a full implementation with all those checkers.
  - 3836293648 3y ago
    Gccrs does not aim to be a full implementation. They're aiming to be a good enough implementation that they can steal the last parts (the borrow checker) from rustc. More specifically they're aiming to steal the next gen borrow checker, not the current one
jmillikin 3y ago
GCC is first and foremost a compiler for GNU C, which is a set of unspecified extensions to C, which is a language that achieved near-universal adoption despite decades of competing mutually-incompatible implementations. C++ templates are Turing-complete, and GCC implements them just fine. The idea that Rust requires a formal specification (outside very rare situations, like aeronautic firmware) is silly.
- Vogtinator 3y ago
  You forgot the </sarcasm> tag. Or are you actually serious with your comment? GCC supports various "flavors" of C, including fully standard compliant versions. GNU extensions are all documented.

alkonaut 3y ago

Why is it necessary to do this? I get that having multiple implementations of a language is a good thing. But why does GCC in particular want to do it, and why with two separate efforts of different levels of ambition? Is it related to rust-in-kernel efforts? What stops using the normal rustc for that?

flohofwoe 3y ago
Because competition and choice is good? Even though having to support multiple C/C++ compilers can be painful at times for programmers, the competition between GCC, Clang and MSVC is definitely a good thing (imagine being stuck with MSVC on Windows when MSVC was about 15 years behind the C standard until recently). A separate Rust compiler may also uncover problems in the language or standard library design (e.g. if it's too much effort to write a Rust compiler from scratch that definitely isn't a good thing IMHO).
- alkonaut 3y ago
  Yes that much I got. It's a thing that would be nice to have. But that doesn't explain exactly why the GCC would be the ones doing it nor why there would be two separate projects.
  - bayindirh 3y ago
    Because having a Free implementation which complements the Open Source one is a great way to keep the language alive, evolve it in a saner way, and improve ways we thought it's impossible to do. clang made gcc and g++ better compilers. gcc-rs can do the same and help making rustc a better compiler and Rust a better language. For the record, I don't write Rust, because GCC has no Rust support yet. More specifically, I don't use LLVM-Specific languages due to LLVM's license and stance against GCC.
    - estebank 3y ago
      How is Rust not evolving in a sane way today?

wiz21c 3y ago

I'd like to point out the quality of the blog post. It is extremely well written. For me it gives a very good sign about where all of this is going.

fithisux 3y ago

Until, then, gdc (gcc dlang) can serve you today.

Shish2k 3y ago
gdc can compile my rust code to obscure embedded targets?

KingLancelot 3y ago

[dead]

philberty 3y ago

The biggest problem Rust has is that "no_core" is so poorly understood at this point that i doubt a comprehensive spec is even possible to explain: 1. Type inference taking into account higher ranked trait bounds - Slices in libcore work via the Index lang item so its like taking an index operator overload to a range lang item but the generic types in the range need to be unified with the higher ranked trait bound to eventually figure out that they are meant to be of usize. 2. Method resolution its almost a joke at this point how complicated it is in Rust. - The autoderef cycle sounds simple when you read this: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/deref-coercions.html - But this misses so much extra context information 3. Macro invocations there are really subtle rules on how you treat macro invocations such as this which is not documented at all https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/expand/rust-macro-expand.cc#L1010-L1017 https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/expan... </rant> Some day I personally want to write a blog post about how complicated and under spec'd Rust is, then write one about the stuff i do like it such as iterators being part of libcore so i don't need reactive extensions.

ChrisSD 3y ago
Hm... I'm not sure I understand. Why would you expect no_core to be specified? It's an implementation detail of rustc, not part of the language.
- philberty 3y ago
  No core _is_ the Rust language, libcore is just a library which adds the "Rust abstractions" so you can actually write a for loop or create a slice or deref, add or anything else. Libcore just gets compiled like any other rust crate just it does not have access to abstractions. For example, you can still write C code without libc because C is a language libc is just a library libcore is pretty much the same. Though Rust makes alot of assumptions that libcore _should_ be there but its possible for it not to be.
  - ChrisSD 3y ago
    core is part of the language (or at least, many parts of it are). The way that rustc currently splits this up is an implementation detail of rustc, not something that must be copied exactly. Rust without core is not Rust. It's not even usable.