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.