gcc实际上可以进行这种优化，即使对于浮点数也是如此。例如

double foo(double a) {
  return a*a*a*a*a*a;
}

变成

foo(double):
    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm1, %xmm0
    ret

使用-O-funcafe数学优化。但是，这种重新排序违反了IEEE-754，因此需要标记。

正如Peter Cordes在一篇评论中指出的，有符号整数可以在没有funsafe数学优化的情况下进行这种优化，因为它恰好在没有溢出的情况下有效，如果有溢出，则会出现未定义的行为。所以你得到

foo(long):
    movq    %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rax, %rax
    ret

只需-O。对于无符号整数，这更容易，因为它们是2的模幂，因此即使在溢出的情况下也可以自由地重新排序。

我根本不会期望这种情况得到优化。表达式中包含可以重新组合以删除整个操作的子表达式的情况不太常见。我希望编译器编写者将他们的时间投入到更有可能带来显著改进的领域，而不是涵盖很少遇到的边缘情况。

我惊讶地从其他答案中得知，这个表达式确实可以通过适当的编译器开关进行优化。要么优化是微不足道的，要么是更常见的优化的边缘情况，要么编译器编写者非常彻底。

像您在这里所做的那样，向编译器提供提示没有错。重新排列语句和表达式，看看它们会带来什么差异，这是微优化过程中的一个正常和预期的部分。

虽然编译器可能有理由考虑这两个表达式以提供不一致的结果（没有适当的开关），但您无需受到该限制的约束。差异将非常小，以至于如果差异对你很重要，你不应该首先使用标准的浮点运算。

另一个类似的情况是：大多数编译器不会将a+b+c+d优化为（a+b）+（c+d）（这是一种优化，因为第二个表达式可以更好地进行流水线处理），并按照给定的方式对其求值（即（（（a+c）+d））。这也是因为角落案例：

float a = 1e35, b = 1e-5, c = -1e35, d = 1e-5;
printf("%e %e\n", a + b + c + d, (a + b) + (c + d));

这将输出1.00000e-05 0.000000e+00

正如Lambdageek指出的那样，浮点乘法是不相关的，你可以得到更少的精度，但当获得更好的精度时，你可以反对优化，因为你想要一个确定性的应用程序。例如，在游戏模拟客户端/服务器中，每个客户端都必须模拟相同的世界，您希望浮点计算具有确定性。

这个问题已经有了一些很好的答案，但为了完整起见，我想指出C标准的适用部分是5.1.2.2.3/15（与C++11标准中的1.9/9节相同）。本节指出，只有当运算符真的是结合的或可交换的时，才能重新组合它们。

因为浮点数学不是关联的。浮点乘法中操作数的分组方式会影响答案的数值精度。

因此，大多数编译器对重新排序浮点计算非常保守，除非他们能够确定答案不变，或者除非你告诉他们你不在乎数值精度。例如：gcc的-fassociative math选项允许gcc重新关联浮点运算，或者甚至-fast math选项，允许更积极地权衡精度与速度。