public inbox for
 help / color / mirror / Atom feed
From: Ian Lance Taylor <>
To: Philip Herron <>
Cc:, David Edelsohn <>,
	 Brad Spengler <>
Subject: Re: Rust Compatibility
Date: Sun, 5 Sep 2021 09:23:48 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Sep 2, 2021 at 7:06 AM Philip Herron <> wrote:
> Yesterday this issue was posted to us on GitHub, 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.


      reply	other threads:[~2021-09-05 16:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 14:06 Philip Herron
2021-09-05 16:23 ` Ian Lance Taylor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).