[mbauman]

I wholeheartedly disagree.

    -Ofast
    
    Disregard strict standards compliance. ...

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.

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Optio...

[nsajko]

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.

[mrguyorama]

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.

[nsajko]

> 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.

[tomrod]

How many programs do you deal with daily that you don't anticipate to follow ISO/IEEE?

[account42]

Most don't really care that much.

[pixl97]

Me: of course I want the FUN SAFE optimization.

They: Sir, that is dash F unsafe!

[Athas]

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.

[nsajko]

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. [...]

[mbauman]

Yes, exactly: I'd deprecate it entirely. It shouldn't be a single flag.