<story><title>Progress toward a GCC-based Rust compiler</title><url>https://lwn.net/SubscriberLink/954787/41470c731eda02a4/</url></story><parent_chain><item><author>VBprogrammer</author><text>I don&amp;#x27;t have a lot of experience in C or C++ but I wonder if this ever works in practice for a non-trivial codebase? I&amp;#x27;d be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them.</text></item><item><author>ndiddy</author><text>Having another Rust implementation allows for an &amp;quot;audit&amp;quot; to help validate the Rust spec and get rid of any unspecified behavior. It would also give users options. If I hit a compiler bug in MSVC, I can file a report, switch to GCC and keep working on my project until the bug is fixed. With Rust, that&amp;#x27;s not currently possible.</text></item><item><author>vlovich123</author><text>The claims in the article feel kinda weak as to the motivation.&lt;p&gt;&amp;gt; Cohen&amp;#x27;s EuroRust talk highlighted that one of the major reasons gccrs is being developed is to be able to take advantage of GCC&amp;#x27;s security plugins. There is a wide range of existing GCC plugins that can aid in debugging, static analysis, or hardening; these work on the GCC intermediate representation&lt;p&gt;&amp;gt; One more reason for gccrs to exist is Rust for Linux, the initiative to add Rust support to the Linux kernel. Cohen said the Linux kernel is a key motivator for the project because there are a lot of kernel people who would prefer the kernel to be compiled only by the GNU toolchain.&lt;p&gt;That explains why you’d want GCC as the backend but not why you need a duplicate front end. I think it’s a bad idea to have multiple front ends and Rust should learn from the mistakes of C++ which even with a standards body has to deal with a mess of switches, differing levels of language support for each compiler making cross-platform development harder, platform-specific language bugs etc etc.&lt;p&gt;&amp;gt; A lot of care is being put into gccrs not becoming a &amp;quot;superset&amp;quot; of Rust, as Cohen put it. The project wants to make sure that it does not create a special &amp;quot;GNU Rust&amp;quot; language, but is trying instead to replicate the output of rustc — bugs, quirks, and all. Both the Rust and GCC test suites are being used to accomplish this.&lt;p&gt;In other words, I’d love gccrs folks to explain why their approach is a better one than rustc_codegen_gcc considering the latter is able to achieve this with far less effort and risk.</text></item></parent_chain><comment><author>jandrewrogers</author><text>Many complex C++ codebases have full parallel CI pipelines for GCC and LLVM. It encourages good code hygiene and occasionally identifies bugs in the compiler toolchain.&lt;p&gt;If you are using intrinsics or other architecture-specific features, there is a similar practice of requiring full CI pipelines for at least two CPU architectures. Again, it occasionally finds interesting bugs.&lt;p&gt;For systems I work on we usually have 4 CI pipelines for the combo of GCC&amp;#x2F;LLVM and ARM&amp;#x2F;x86 for these purposes. It costs a bit more but is generally worth it from a code quality perspective.</text></comment>
<story><title>Progress toward a GCC-based Rust compiler</title><url>https://lwn.net/SubscriberLink/954787/41470c731eda02a4/</url></story><parent_chain><item><author>VBprogrammer</author><text>I don&amp;#x27;t have a lot of experience in C or C++ but I wonder if this ever works in practice for a non-trivial codebase? I&amp;#x27;d be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them.</text></item><item><author>ndiddy</author><text>Having another Rust implementation allows for an &amp;quot;audit&amp;quot; to help validate the Rust spec and get rid of any unspecified behavior. It would also give users options. If I hit a compiler bug in MSVC, I can file a report, switch to GCC and keep working on my project until the bug is fixed. With Rust, that&amp;#x27;s not currently possible.</text></item><item><author>vlovich123</author><text>The claims in the article feel kinda weak as to the motivation.&lt;p&gt;&amp;gt; Cohen&amp;#x27;s EuroRust talk highlighted that one of the major reasons gccrs is being developed is to be able to take advantage of GCC&amp;#x27;s security plugins. There is a wide range of existing GCC plugins that can aid in debugging, static analysis, or hardening; these work on the GCC intermediate representation&lt;p&gt;&amp;gt; One more reason for gccrs to exist is Rust for Linux, the initiative to add Rust support to the Linux kernel. Cohen said the Linux kernel is a key motivator for the project because there are a lot of kernel people who would prefer the kernel to be compiled only by the GNU toolchain.&lt;p&gt;That explains why you’d want GCC as the backend but not why you need a duplicate front end. I think it’s a bad idea to have multiple front ends and Rust should learn from the mistakes of C++ which even with a standards body has to deal with a mess of switches, differing levels of language support for each compiler making cross-platform development harder, platform-specific language bugs etc etc.&lt;p&gt;&amp;gt; A lot of care is being put into gccrs not becoming a &amp;quot;superset&amp;quot; of Rust, as Cohen put it. The project wants to make sure that it does not create a special &amp;quot;GNU Rust&amp;quot; language, but is trying instead to replicate the output of rustc — bugs, quirks, and all. Both the Rust and GCC test suites are being used to accomplish this.&lt;p&gt;In other words, I’d love gccrs folks to explain why their approach is a better one than rustc_codegen_gcc considering the latter is able to achieve this with far less effort and risk.</text></item></parent_chain><comment><author>Guvante</author><text>Our codebase works on all three, we compile on MSVC for Windows, GCC for Linux, and Clang for Mac.&lt;p&gt;It isn&amp;#x27;t easy and honestly the idea of &amp;quot;just don&amp;#x27;t use MSVC for a while&amp;quot; is strange to me. Sure you can compile with any of them but almost certainly you are going to stick to one for a given use case.&lt;p&gt;&amp;quot;This release is on a different compiler&amp;quot; isn&amp;#x27;t something you do because of a bug. Instead your roll back a version or avoid using the unsupported feature until a fix is released.&lt;p&gt;The reason is as much as they are supposed to do the same thing the reality is bugs are bugs, e.g. if you invoke undefined behavior you will generally get consistent results with a given compiler but all bets are off if you swap. Similarly it is hard not to rely on implementation defined behavior without building your own standard library which specifically defines that behavior across compilers.</text></comment>