-Ofast isn't a good name for the option, but in GCC's defense the manual is pretty clear about all this, and there's no excuse for blindly turning on compiler options - they literally change the semantics of your code.
There's strict standards compliance and then there's the crazy grab bag of code changes that is `-ffast-math`. Further, I'd say gevent can defensibly say that -ffast-math is okay for them given what the manual says:
-ffast-math
... it can result in incorrect output for programs that depend on an exact
implementation of IEEE or ISO rules/specifications for math functions.
It may, however, yield faster code for programs that do not require the
guarantees of these specifications.
This is 100% on the compiler people. For the option name, the documentation, and the behavior.
Well, how would you improve the docs? Both documentation entries seem reasonable to me.
That said, I don't see why the -Ofast option even needs to exist, except backwards compatibility, as -ffast-math and the others can (and should IMO) be specified explicitly.
The fact that -ffast-math makes no mention that it will poison any other code executing in your process space is a huge missing point of info. Docs as written, anyone not doing scientific math should have that flag, but the reality is that most people have some code somewhere in their process that expects fairly sane floating point math behavior, even if it's just displaying progress bars or something.
> The fact that -ffast-math makes no mention that it will poison any other code executing in your process space
Untrue. The doc entry for -ffast-math says "can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions". Emphasis mine.
So they clearly say that the entire program can turn invalid when -ffast-math is used.
You and some other people here act like the docs say "translation unit" or something like that, instead of "program", but this is simply not the case.
Furthermore, the entry for -ffast-math points to entries for suboptions that -ffast-math turns on (located right below in the man page), e.g. -funsafe-math-optimization. These also make clear how dangerous they can be even when turned on one at a time.
Consider the documentation for the similar compiler flag in the OpenCL specification:
> -cl-unsafe-math-optimizations
> Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid, (b) may violate IEEE 754 standard and (c) may violate the OpenCL numerical compliance requirements as defined in section 7.4 for single-precision floating-point, section 9.3.9 for double-precision floating-point, and edge case behavior in section 7.5. This option includes the -cl-no-signed-zeros and -cl-mad-enable options.
While it stops short of saying "this will likely break your code" (maybe because it doesn't have the nonlocal effects of -ffast-math), it makes it much more clear that this flag is generally unsafe and fragile, except under rather specific circumstances. Also, it is reasonably exact about what those circumstances are. I'm not sure -ffast-math is documented with enough precision for a programmer to even know whether it will break their code. Best you can do is try and see if the program still works.
The relevant GCC man page entries are even more clear than the OpenCL spec excerpt.
-ffast-math:
> This option is not turned on by any -O option besides -Ofast since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions.
It also point to the -funsafe-math-optimizations sub-option, where it is said that:
> Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link time, it may include libraries or startup files that change the default FPU control word or other similar optimizations. [...]
What's missing is that it also affects linking, and results in this strange action-at-a-distance. Maybe disabling the linker part with -shared would be a reasonable compromise.
You're wrong, both the doc entry for -Ofast and the one for -ffast-math say that they can result in incorrect programs. Programs are produced by linking, so I don't see what other way to interpret this is possible.
Why not simply replace all FP math with a constant zero? That’d be really fast and an equally valid strict interpretation of “can result in incorrect programs.”
Just because you’re shallowly dismissing my comment doesn’t make it wrong.
Linking in code with undefined (in this case, redefined) behavior doesn’t automatically invalidate the entire program. But thats the language used because once the undefined behavior is hit at runtime, the spec no longer defines what the behavior is and what the program will do afterwards.
> It's hard to come up with a similar name that isn't long.
The suggestion given elsewhere in these comments to call it "unsafe math" instead of "fast math" sounds good. It's nearly as short, and properly conveys the "you must know what you're doing" aspect of these flags. It's even better if you're used to Rust.
I agree. I think --ffast-math should actually be called --finexact-math. One would also hope that explicitly disabling an option on the command line would, you know, explicitly disable the option, but maybe that's too much to ask.
I don't think it should exist at all. It's such a crazy grab bag of code changes disguised as "optimizations" that it's completely impossible to reason about, even for folks that "don't care" about the exact floating point arithmetic.
It has global effects like those in TFA, and even locally you no longer know if a line or two of arithmetic will become more precise (e.g., by using higher precision intermediate results), less precise, or become complete gibberish (e.g., because it thinks it can prove you're now dividing by zero and thus can just return whatever it wants).
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Optio...