I am forking this off from the RFC that discusses and implemented the deprecation of Ofast because:
- that RFC has 100+ messages now and discusses various things at the same time,
- I have left questions about the approach that are not being answered, so I want to focus on that here.
The original problem description in the original RFC was: Ofast is a footgun and users don’t understand fast math. The solution is to deprecate and remove Ofast in 2 years to protect users from themselves.
My questions that are not being answered are:
- Why do we need to deprecate and remove a user facing option that has existed for 15 years to achieve that goal?
- Why can’t we emit a warning when Ofast is enabled on the command line now that we have learned that GCC has no intentions to deprecate the option?
- Why can’t we emit a useful “rustc-like diagnostic” what the problem is with Ofast and what the options are, possibly pointing to documentation explaining this all further?
The compatibility with GCC is extremely valuable and eventually removing this option means we will forever be dealing with questions:
- why does this option not exist in Clang, and
- why is my FP code slower than GCC?
For this discussion, I would like to define compatibility as having the Ofast option available, and would like to consider the exact meaning of Ofast as an orthogonal discussion. Optimisations levels can change and they do change, and that is all fine.
My questions also ignore valid use cases of Ofast, the problematic name of the option, etc., but here I would like to focus on compatibility and why we can’t address the problem with a diagnostic without eventually removing the option in order not to break compatibility.
I also have problems with the process how this was implemented, i.e. how some “requirements” crept into a very long RFC, how consensus was called, how this was merged just before branching, the order of events, and all the post-merge comments on the RFC illustrating this is controversial and probably justifies a revert. But I do not want to focus on the process side of things here, nor am I necessarily looking for a revert. I am only interested in solving the problem and progressing this, which again is addressed by my questions why instead of deprecating this we can’t solve this with a diagnostic and documentation update? To implement this, that is a very small delta on the patch that implements this, so that isn’t the issue if we want to do this just before branching.
Can folks please answer the questions that I raised?