Re: Rust Compatibility

[Ian Lance Taylor <iant@golang.org>]

On Thu, Sep 2, 2021 at 7:06 AM Philip Herron <philip.herron@embecosm.com> wrote:
>
> Yesterday this issue was posted to us on GitHub https://github.com/Rust-GCC/gccrs/issues/653, which revolves around strict-aliasing rules.
>
> The conversation was focused on what level of compatibility we are aiming for in the Rust language. This is important, and I don't believe we should allow specific language features/development outside the official Rust processes. This means we do not want to have any GCC specific attributes or language features and we won't provide a shortcut to bypass RFC processes.
>
> Though I believe we should always allow users to invoke GCC Rust however they wish (since the FE inherits the common GCC options), this is the point of free software to me. To mitigate any GCC vs Rustc incompatibility, our cargo-gccrs wrapper was always intended to map rust arguments over to the GCC version of these to get the intended Rustc behaviour. But still, when users want to invoke gccrs directly, it is up to them to choose what options they want, good or bad, including using gcc-plugins.
>
> Some of the feedback seems that if we allow users to compile code with or without strict aliasing, this may allow for code to compile with GCC but not with rustc which "splits the ecosystem". So I wanted to run this by you guys here to get feedback on what people think about allowing users to choose their GCC compilation options in general.

Using that rather strict sense of splitting the ecosystem, there are
various GCC optimization options that will split the ecosystem,
because they will cause code to behave differently.  It's not just
-fstrict-aliasing, it's also options like -ffast-math or
-fexcess-precision which can all cause code to be compiled
differently.  Your choice is to either carefully forbid those options
for Rust or to permit them and warn people accordingly.  Personally I
would favor permitting them.

Ian