使用GCC -mfpmath=387与-O2/-O3编译程序为何产生NaN值？

核心原因：x87扩展精度与编译器优化的交互 #

你的NaN结果源于x87浮点单元（FPU）的80位扩展精度存储，结合GCC特定版本的优化策略，导致中间计算出现未预期的数值溢出，进而产生NaN。

具体过程拆解 #

1. z值的精度偏移
   代码中z从-1.0开始，每次累加2.0/(n-1)（n=11时步长为0.2）。理论上10次累加后z应等于1.0，但由于浮点数二进制表示的局限性，实际在x87的80位寄存器中，z的最终值是略大于1.0的80位浮点数（而非精确的1.0）。

2. 负数开平方触发NaN
   当z略大于1.0时，1 - z*z会得到一个极小的负数。此时sqrt(1 - z*z)会返回NaN，因为平方根函数对负数无定义。

3. 存储时的精度截断
   当把z写入result数组时，80位的z会被截断为64位double类型。这个截断操作会把略大于1.0的80位值舍入为精确的1.0，所以你看到输出的z是1，但r已经是NaN，最终x和y也变成NaN。

为什么只有满足特定条件才会触发？ #

你列出的所有条件都是上述过程发生的必要前提：

• -mfpmath=387与优化等级：x87是唯一使用80位扩展精度的x86浮点指令集，-O2/-O3会让编译器尽可能将中间结果保留在寄存器中（不刷入内存截断精度），这才会让z保持80位的略大于1.0的值。
• 64位myint：GCC对64位循环变量的优化策略与32位不同，会更倾向于保留寄存器中的浮点值，而非提前截断到64位。
• 列优先存储：列优先的内存访问模式是非连续的，编译器无法通过内存操作优化强制截断z的精度；如果是行优先，连续的内存存储会更早触发精度截断。
• 无printf()调用：printf()会强制将寄存器中的浮点值刷入内存（转换为64位），提前截断了z的80位精度，避免了z略大于1.0的情况。
• GCC版本差异：GCC 10.2及以后的版本优化策略做了调整，会更及时地将x87寄存器中的值截断为64位double，避免了这种精度偏移导致的溢出问题。

为什么数学上看似没问题？ #

从数学逻辑上z应精确等于1.0，但浮点数的二进制表示无法精确存储0.2这样的十进制小数，累加后的误差在x87的80位精度下被保留，最终导致z超出了1.0的范围——这是浮点数运算的固有特性，结合编译器优化策略才触发了NaN。

内容的提问来源于stack exchange，提问作者Szabolcs