The help text is modified to say that Ofast is Deprecated; use '-O3 -ffast-math' for the same behavior, or '-O3' to enable only conforming optimizations.
A warning similar to the help text is emitted if the user invokes Clang with the Ofast option.
The situation currently in Flang is that the Ofast help message says the same as Clang, i.e Ofast is deprecated. No warning is emitted if a user invokes Flang (flang-new) with the Ofast option. This is an unfortunate situation and I think we should either
→ Match what Clang does and make the LLVM frontends consistent. i.e add a warning to a Flang Ofast invocation saying that the option is deprecated
or
→ Decide that Flang and HPC community are sufficiently different and remove the deprecated help text in Flang by restricting the deprecated messsage to Clang only.
My understanding is that they are not. The following post talks about the case of Kahan summation where fast-math can provide the wrong answers.
@everythingfunctional mentioned in the call today that fast-math can do transformations that violate the order of transformations. But he also said that he is not sure about the deprecation since it seems too dependent on users understanding the effects of -ffast-math better than -Ofast. @kparzysz disagrees.
In a prior post @jeffhammond mentions that he uses tests to ensure that use of -ffast-math do not violate the accuracy requirements for the applications that he writes.
The Fortran standards have always allowed great leeway to compilers to transform expressions to anything that is “mathematically equivalent”.
F’2023 10.1.5 p7–8: "Once the interpretation of a numeric intrinsic operation is established, the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated.
Two expressions of a numeric type are mathematically equivalent if, for all possible values of their primaries, their mathematical values are equal. However, mathematically equivalent expressions of numeric type can produce different computational results."
My understanding of -ffast-math is that it includes transformations that do not respect parentheses (or their equivalent (10.1.8), store-load forwarding). But I could be wrong or out of date on that, and its definition is of course not guaranteed to be portable across compilers, which is what really matters anyway.
Addendum: I skimmed the GCC documentation for -ffast-math and it does imply -fassociative-math, which is a basket of parentheses-violating rewrites like (a+b)-a to b.
Just wanted to revive the thread here. For LLVM 19, the deprecation message (for Ofast) was restricted to Clang. This means that if the Ofast option is used with Clang it produces a warning. Deprecated; use '-O3 -ffast-math' for the same behavior, or '-O3' to enable only conforming optimizations . Note that this is only a warning and there is no change in functionality, but the plan is for an eventual removal of Ofast subject to community approval.
No such warning is produced for Flang. Do we want to enable the warning for Flang in LLVM 20?
From the previous reply of @klausler it looks like Ofast breaks the parantheses ordering and hence is not conforming. I think it also breaks the functionality provided by the IEEE modules and intrinsics like ieee_is_nan will not work as expected.
As an programmer using Fortran along with C/C++ (not developing compilers), I would very much would like that Clang and Flang have more or less the same flags working the same way (where it is not controlling language-dependent features, of course). Following Clang here seems like a very wise choice.
(I also think way too many just throw in -Ofast as a flag because they want fast computations, without understanding the consequences)