After reading through all the feedback so far, I find the points raised in favor of emitting a deprecation warning compelling. I particularly appreciate the point that a deprecation warning raises visibility and aids in user education, which is ultimately a good thing for the ecosystem as a whole.
So, I’d like to modify the proposal in that light. I think there’s two options:
Make -Ofast equivalent to -O3, and emit a deprecation warning at the same time. The warning would mention that the behavior is now -O3, but you should add -ffast-math if you want to retain the old behavior.
Have -Ofast remain equivalent to -O3 -ffast-math, and emit a deprecation warning saying you should switch to either -O3 or -O3 -ffast-math as appropriate.
I’d prefer the second option now. If we’re going to emit a warning, I don’t see a significant reason to also change the behavior at the same time.
In terms of timeline to ultimately remove the flag – I don’t think there’s a need to rush. If we want to deprecate for 2 years before removal, I have no objection there.
Agreed. We’re in a bit of a difficult spot in that we want to be GCC-like enough that you can reasonably migrate between Clang and GCC with limited amounts of pain, but we do not want to be a drop-in replacement for GCC in terms of restricting ourselves to only following their approach.
Perhaps, but that also sounds like creating significant pain for users (and tools like CMake) for a questionable amount of benefit. It would take a lot of research to figure out what a reasonable middle ground is.
That said, my point is more that we are already in a situation where existing options in Clang and GCC have [un]intentionally different behaviors, including the behavior of -Ofast, so this proposal doesn’t make us inconsistent with GCC, it widens an existing inconsistency with a compelling rationale for why that’s reasonable.
My preference is for the second option; it leads to less surprises when upgrading Clang versions while still alerting users to the fact that a future upgrade will require them to update their build flags.
Is there an appetite for ‘both’? Basically, 3 steps:
1- No change to behavior, but warn that -Ofast is changing
2- Change to be an alias for O3, but warn that -Ofast HAS changed
3- Remove -Ofast completely
I think this gives folks a good amount of time/differences in warnings to pay attention to this. It also changes from “oh this is something I can deal with later (1), to this is something I should look into now(2), to this is something I NEED to look into now”.
So I think it provides 3 separate, useful ‘pings’ to users.
As far as schedule, 1 year for each of the 1st 2? or 3 releases each? WDYT?
One thing that concerns me is what @AaronBallman alluded to about “the difficulties that sometimes arise from maintaining a build system.” A lot of the discussion here has seemed to make the assumption that it’s a trivial thing to just replace “-Ofast” with “-O3 -ffast-math” in your makefiles. That would be true if your build system was straightforward and well understood, but my experience is that that isn’t always the case. A lot of legacy projects have very convoluted build systems that no one wants to touch because the current owners aren’t really sure how they work.
I’d also note that replacing “-Ofast” with “-O3 -ffast-math” might give you the same behavior you’re currently getting with clang, but it will change what you’d get if you use the same build system with gcc.
The thing that worries me here is that once we remove support for “-Ofast” there are going to be people who are considering migrating from gcc to clang, but when they try it out they’ll find that clang doesn’t support the “-Ofast” option and they may not be willing to work around it. I think we’ve got a whole list of options that are accepted by the driver but don’t actually do anything for this reason.
Of course, that’s only a problem once we actually remove the option.
I do find myself liking the idea of the intermediate state where the option continues to work but we tell the user that it is a dangerous option and they shouldn’t be using it. We should talk to the gcc folks about this too, because it’s no better for them and, like clang, they have bugs in their implementation of it.
So I guess I’d be on board with option 2 as presented above by @jyknight with the understanding that we might want a much longer than usual deprecation period. Personally, I don’t see a problem with keeping the support indefinitely once we are telling users that it probably does things they don’t intend.
Here’s something I realized on the way home tonight that is simultaneously a demonstration of what a cursed option -Ofast is and a demonstration that -O3 -ffast-math doesn’t provide a simple replacement.
clang -Ofast -O2 foo.c
What do you think? Is fast-math enabled? Nope. Because -Ofast is an optimization level option, -O2 supersedes it. But, of course, -O3 -ffast-math -O2 does enable fast-math.
Clang’s docs for flags needs to improve in general. It’s currently an extremely long page with a couple sections (and not all flags seem to be sorted correctly between them). A majority of the flags aren’t documented or have really minimal documentation that isn’t helpful. GCC’s documentation is also long but separated into sections and generally has more guidance than just precisely what each flag does. I’ll also note that the Clang page for compiler options specifically calls clang and clang++ “GCC-compatible”.
This is something that I’ve been planning on working on for a while because Clang has many flags which are neither documented nor exist on GCC. I’ve read all of GCC’s docs and most of Clang’s. A few messages here have mentioned us pointing towards GCC’s docs for places where Clang tries to be compatible but I haven’t seen that.
I’m a long way away from this issue, but as a daily user of clang, I don’t understand the proposal to make -Ofast be accepted but be an alias for -O3. In my opinion, this is some attempt to cast judgement on a flag that GCC defined, and redefine it in a way that will just make clang look bad on benchmarks. If we want to take the stance that this flag is “bad” for some reason, then I think it would make sense to recognize the options and reject it with an error (saying that you can get this behavior with -O3 -ffast-math) so that users known what is going on.
Silently accepting it and doing something different than gcc does just seems the worst of both worlds.
I think this is a very good suggestion for deprecation message wording.
warning: -Ofast enables a non-standard language dialect. Replace it with -O3 -ffast-math to explicitly enable fast-math optimizations, or just -O3 to use standard optimizations [-Wdeprecated]
Yeah exactly. Not sure if silently accepting -Ofast, and doing something that wasn’t it’s intent to begin with, will be any improvement from all the arguments currently being made against it.
Discussion on this topic seems to be winding down, so I think now may be a good time to determine next steps for the proposal.
My reading of the comments on the thread is:
We have consensus against aliasing -Ofast to -O3
We have consensus for leaving the current behavior of -Ofast alone, but deprecating the flag and recommending users switch to either -O3 or -O3 -ffast-math as appropriate
The -Ofast will eventually be removed.
The deprecation period should be lengthy enough for users to migrate before we remove the flag; two years seems to be a suggestion with support
We would like to see improved documentation for this flag
Coordination with GCC would be appreciated but is not a requirement; if they have strong technical arguments to retain the flag, that might warrant re-opening the RFC
If you have a strong opinion to the contrary, please voice it ASAP, but otherwise I believe this RFC is accepted.
Rereading messages, it wasn’t obvious to me that a clear consensus was reached. I somehow missed the last couple of messages, so I missed this deadline:
If you have a strong opinion to the contrary, please voice it ASAP, but otherwise I believe this RFC is accepted.
I am surprised no one else replied, so maybe fair enough, maybe that means there was consensus, but I am just not entirely sure about that.
I just noticed that this patch went in. I find it very disappointing to see that the required documentation changes and improvements didn’t start with this patch. In the clang documentation, we now only say that -Ofast is deprecated and that -O3 -ffast-math should be used, so what has changed? This doesn’t explain what the “footgun” is, what the safe subset of fast math flags are, what the unsafe ones are, and their benefits, so I am very unimpressed with all of this.
Whether we call it safe, less harmful, or something else, I think my point still stands: nothing is explained or documented, so this is not an improvement and very disappointing given that the main thesis was that users don’t understand these options.
We don’t need to take away the option to achieve the same things: a warning message could still be emitted but then actually explaining what the alternatives are, in combination with some proper documentation. That would be my counter proposal.
I think deprecating -Ofast is a worthwhile experiment, that if done at the beginning of the LLVM 20 dev cycle, would give the GCC community 6 months to achieve consensus on whether both LLVM and GCC should uniformly deprecate this flag, without tradeoffs.
I do value compatibility with GCC in terms of flags more than the bugs this deprecation would catch (and the new bugs it may introduce as pointed out by Andy Kaylor here (RFC: Deprecate -Ofast - #67 by andykaylor), i.e., I think trading off one for the other is a bad deal for clang, in which case I’d be then in favor of reverting the deprecation before the LLVM 20 release.
Doing this a few weeks before the LLVM 19 release means that unless the GCC community achieves consensus over the next few weeks on this issue, I’d be in favor of reverting this experiment before the LLVM 19 release. That unnecessarily risks putting a worthwhile experiment to rest forever.
Can someone point me to our engagement with the GCC community on this issue? Which direction is consensus about this in their community swaying towards?
The deprecation message here isn’t going to change any behaviors - but I think the intended change will cause a lot of pain for users in the long term, even if it’s short term pain for them. If the actual final intended change is ever pushed, a lot of users are going to have scripts broken, verification tests broken, performance lost, and overall a lot of people will spend a lot of time trying to figure out what the heck happened and how to get back their default behavior.
And the lack of documentation will not help that. This feels like moving the gun from one foot to the other.
As a slight twist, what about suggesting -funsafe-math-optimizations instead of -ffast-math (they are aliases right?).
The naming “unsafe-math-optimizations” is much more explicit about what we do with this option than “fast-math”! (I remember being a young engineer and enabling “Ofast” and/or “fast-math” and thinking “why wouldn’t I want faster math!?”).
This is not fully accurate; we document the behavior of the various floating-point command line options and we do tell users that they impact the correctness of results. That said, our documentation can always be improved and so I’d be happy to see further improvements here if folks have concrete suggestions. The documentation for -Ofast itself is not the appropriate place to tell users about why fast math is dangerous though, so I’m not certain I see many improvements to those docs beyond some cross-linking (but maybe others have better ideas).
The Clang 19 release schedule for final is roughly September, this RFC was posted in April, consensus called at the beginning of June, and patch landed in mid July, so there’s been time and still remains time for GCC to make decisions for their compiler. However, coordination with GCC is not a requirement, either.
CC @jyknight@Endill to see if they’ve had any conversations with GCC folks on this.
We certainly can change direction if there’s new information about concrete problems the changes have caused, but “we want more documentation” is not a reason to revert the changes. The patch did not change the behavior of -Ofast, it told users the option is deprecated. Please keep in mind that users do not expect optimization flags to make non-conforming behavioral changes that impact the correctness of valid, well-formed code; that some folks in specific industries do know of the dangers is not a reason to retain a feature which is generally thought of as “optimize for speed” because it’s named fast.