Rust front-end merged in GCC trunk

I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc? rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work.<p>¹<a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;tree&#x2F;master&#x2F;compiler&#x2F;rustc_codegen_gcc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;tree&#x2F;master&#x2F;compiler&#x2F;rustc...</a>

I hope there aint gonna be ecosystem fragmentation<p>When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem<p>I hope it will be used only where necessary

What are the practical implications of this? Could cargo call GCC? Or would it be like gcj and allow compiled rust libraries &amp; binaries to be distributed? (at least in theory, gcj didn&#x27;t work out well)

Probably a dumb question, but I&#x27;d really like to know if this somehow affects&#x2F;improves Rust&#x27;s support for dynamic linking in any way (i.e., when comiling Rust code with the GCC-based toolchain, instead of with rustc)?

Does this mean I can now finally generate object files from .rs sources and link them myself?<p>That is one of the things that rustc is severely lacking.

Their base62 implementation really looks unreviewed. A static 64 byte array for 62 bytes...