> Floating-point users today are accustomed (or resigned, sometimes) to compilers that make invalid optimizations by assuming all arithmetic is mathematically correct instead of rounding.<p>Huh? Modern compilers don't do that. They will only reorder or re-associate operations if they know that it will produce the exact same result. Anything else is considered a severe compiler bug. The exception is if you explicitly ask for such sketchy optimizations with the `-ffast-math` flag, of which the GCC man page says: "This option is not turned on by any -O option besides -Ofast since it can result in incorrect output for programs." This option is off by default. The rest of the article is interesting, if correct – unfortunately, it's a little hard not to be skeptical when the first sentence is so flagrantly wrong.
Undesirable and surprising, yes, but incorrect? The manual clearly describes the behaviour and AFAIK, there wasn't a fortran standard yet.<p>I guess the reordering was done to simplify later compiler passes, in particular the common subexpression elimination one.
The "not grouped by parentheses" is already where things go wrong. Parentheses should determine the syntactic parse of the expression, not the order of evaluation. Optimization works with an abstract representation of the program where the parenthesis tokens are long gone.<p>That is to say (a + b) + c should not have any influence relative to a + b + c, at least if addition is already left associative. Because then a + b + c <i>already means</i> (a + b) + c. Adding the parentheses to make (a + b) + c doesn't change the parse whatsoever.<p>If parentheses are needed to establish the precise meaning, it means that the compiler writer has neglected to document, and commit to, an associativity for the operator; the compiler writer has not specified whether a + b + c means (a + b) + c or a + (b + c). That is a mistake: a gratuitous ambiguity in the syntax of the programming language.<p>If there is such a mistake in the design, a stray ambiguity, then you cannot call the optimization wrong. If it is not specified whether a + b + c means (a + b) + c, or a + (b + c) or something else like add3_in_any_order(a, b, c), then the compiler is in fact free to use any of the possible parses as a guide for the operation order.
If you want really accurate math, the best idea for a program is maintain a representation of an expression until it absolutely needs to, since every time the math is condensed into actual numbers there is usually some loss of precision. Even as humans, it makes sense, we rarely write 0.33333 instead of 1/3 unless we have to by circumstance (or at least you souldn't)