But why

Posted Oct 2, 2024 18:17 UTC (Wed) by glaubitz (subscriber, #96452)
In reply to: But why by jbills
Parent article: An update on gccrs development

> This argument isn't helpful, as neither gccrs nor rustc_codegen_gcc are feature complete, so neither of them can compile rustc for these targets.

We were talking about obscure targets and software in general, not just gccrs on sh4, for example.

I have discovered many bugs on architectures such as SPARC that were not immediately visible on x86_64, yet they existed and they eventually needed to be fixed as they could still show on x86_64 under certain circumstances.

Outside of Rust, I just discovered a GCC regression while testing patches for the SH backend which affected x86_64 as well and existed since version 9.x. It just happened to have never triggered the internal compiler error as no one didn't test what I tested before.

> You haven't given any reason why rustc_codegen_gcc couldn't do this in the future. Development on it is slow, but that is because essentially one dev is working on it. If the project had the resources of gccrs, then it could potentially be feature complete by now.

I have already successfully compiled simple Rust code using gccrs while I haven't been able to do that using rustc_codegen_gcc. And you're also answering the question yourself: Despite rustc_codegen_gcc already being part of the official upstream Rust git repository, hardly anyone inside the Rust team is interested in supporting the project, despite people constantly using the project as an argument against gccrs.