Editing Floating-point arithmetic (section)

=== "Fast math" optimization ===
The aforementioned lack of [[Associative property|associativity]] of floating-point operations in general means that [[compilers]] cannot as effectively reorder arithmetic expressions as they could with integer and fixed-point arithmetic, presenting a roadblock in optimizations such as [[common subexpression elimination]] and auto-[[Single instruction, multiple data|vectorization]].<ref name="Vectorizers"/> The "fast math" option on many compilers (ICC, GCC, Clang, MSVC...) turns on reassociation along with unsafe assumptions such as a lack of NaN and infinite numbers in IEEE 754. Some compilers also offer more granular options to only turn on reassociation. In either case, the programmer is exposed to many of the precision pitfalls mentioned above for the portion of the program using "fast" math.<ref name="FPM"/>

In some compilers (GCC and Clang), turning on "fast" math may cause the program to [[Subnormal_number#Disabling_subnormal_floats_at_the_code_level|disable subnormal floats]] at startup, affecting the floating-point behavior of not only the generated code, but also any program using such code as a [[Library (computing)|library]].<ref name="harmful"/>

In most [[Fortran]] compilers, as allowed by the ISO/IEC 1539-1:2004 Fortran standard, reassociation is the default, with breakage largely prevented by the "protect parens" setting (also on by default). This setting stops the compiler from reassociating beyond the boundaries of parentheses.<ref name="Gen"/> [[Intel Fortran Compiler]] is a notable outlier.<ref name="zheevd"/>

A common problem in "fast" math is that subexpressions may not be optimized identically from place to place, leading to unexpected differences. One interpretation of the issue is that "fast" math as implemented currently has a poorly defined semantics. One attempt at formalizing "fast" math optimizations is seen in ''Icing'', a verified compiler.<ref name="Becker-Darulova-Myreen-Tatlock_2019"/>