Progress toward a GCC-based Rust compiler

Original Article ↗ Hacker News Discussion ↗

A planned Rust front end for GCC is reigniting debate over whether the language should have multiple independent compilers or continue to rely on the canonical `rustc` implementation. Proponents argue that a GCC-based Rust (gccrs) would bring access to GCC’s analysis plugins, broader CPU and embedded support, GPL-licensed tooling, and valuable cross-checking for a future Rust language specification, which safety‑critical industries increasingly demand. Critics counter that duplicating the front end wastes scarce effort, risks C++‑style fragmentation and incompatible “flavors” of Rust, and that existing efforts—like `rustc` with a GCC backend and the Ferrocene-qualified toolchain—already address most practical needs without creating a parallel compiler ecosystem.

Motivation for gccrs vs. alternatives

  • Stated goals: use GCC’s existing security/analysis plugins, support Rust for Linux in GNU-only toolchain environments, provide a GPL-licensed, LLVM-independent Rust compiler.
  • Supporters highlight better coverage of GCC-only architectures (e.g., Dreamcast/SH‑4, legacy CPUs, some RISC‑V configs, mips64) and easier use where GCC is entrenched.
  • Critics argue rustc_codegen_gcc (GCC backend driven by rustc frontend) delivers most benefits with far less effort and is already compiling the Linux kernel.

Multiple frontends and fragmentation

  • Pro‑multiple‑impls: helps “audit” the language, expose underspecified behavior, reduce single‑implementation risk, and give users options when hitting compiler bugs.
  • Anti‑frontends: C/C++ are cited as warnings—different vendors, flags, bugs, and feature gaps make portable code harder. Many Rust users value today’s “one compiler, works everywhere” property and fear “GNU Rust” or vendor forks.
  • Some suggest multiple frontends mostly duplicate effort and create subtle incompatibilities for library maintainers.

Language specification and standardization

  • Many argue Rust needs a formal spec/standard; some industries and regulators reportedly require it for safety‑critical use.
  • Others say Rust already has RFCs, a Reference, and an active spec project; a C++‑style ISO process is seen as slow and unnecessary.
  • Distinction is drawn between a descriptive spec of current behavior vs. a prescriptive ISO standard; some want the former without the latter.

Safety‑critical Rust and Ferrocene

  • Ferrocene (a qualified Rust toolchain) is cited as proof Rust can meet standards like ISO 26262/IEC 61508 without a formal language standard, via a detailed spec of a specific compiler version.
  • Counterpoint: absence of an official language standard still disqualifies Rust for some domains and is perceived as “not serious” by certain organizations.

Toolchains, architectures, and bootstrapping

  • gccrs is welcomed by those wanting Rust on GCC‑supported but LLVM‑unsupported or neglected CPUs, and by people who prefer a “pure GNU” or GPL toolchain.
  • Others note GCC itself has complex bootstrapping and that binary toolchains and cross‑compilation already solve most practical bootstrapping problems.

Governance, monopolies, and evolution speed

  • Some distrust a single implementation “monopoly” and want competition; others argue an open, community‑run canonical compiler is unlike a corporate monopoly and avoids browser‑style fragmentation.
  • Rust is criticized both for moving too fast on features (complexity) and too slowly on some long‑requested ones; multiple frontends and a formal standard are seen by some as further drag, by others as necessary maturation.