Mac 上 Intel Fortran 编译器的结果不正确，但在 Linux 上正常答案

【问题标题】：Incorrect result with Intel Fortran Compiler on Mac, but fine on LinuxMac 上 Intel Fortran 编译器的结果不正确，但在 Linux 上正常
【发布时间】：2011-04-23 22:21:24
【问题描述】：

我一直在使用 Fortran 中的快速多极代码。它对我来说是一个黑匣子，在我的mac上编译它时我一直有一些奇怪。

我使用的是 11.1 版的编译器，我有一台运行 2.5 GHz Intel Core 2 Duo on Snow Leopard 的 MacBook Pro。

当我将优化标志设置为 -O0 时，代码运行良好，但在我使用 -O2 或 -O3 时失败。奇怪的是，代码在 Linux 机器上运行良好，至少使用默认的 -O2 标志。

有人对导致问题的原因有任何想法吗？它必须是带有矢量化的东西。

【问题讨论】：

你在 Linux 上使用完全相同的 ifort 版本吗？无论如何，“......只要将机制视为黑匣子，就不可能令人信服地证明正确性，......”（c）Edsger Wybe Dijkstra
我必须检查一下（它在我目前无法访问的计算机上），不过我对此表示怀疑。
它也适用于 Windows 上的 Lahey 编译器。

标签： macos optimization fortran intel

【解决方案1】：

乍一看，没有任何进一步的信息，我直接得出结论，您的程序不稳定；也就是说，当您调整优化（对生成的代码有各种影响）时，您的程序会产生非常不同的结果（在某些情况下失败与非失败）。一些调整会对浮点运算的结果产生影响，这很容易导致长时间运行的科学模拟的成功与失败。

这是程序潜在“问题”的症状，我建议您不要依赖程序“成功”运行的结果，直到您更好地理解它 - 您需要打开黑盒子，看看里面有什么。

至少你应该测试你的程序对输入的微小变化的敏感性。

【讨论】：

你可能是对的。唯一需要注意的是，这是一个经过彻底测试的代码。它使用 FMM 计算 n 体相互作用，但将结果与直接计算进行比较，因此很容易看出您是否得到了正确的答案。 mac 上的势能输出为 NaN，优化已打开，但在关闭时正确。它在 linux 机器和 Windows 上运行良好...
NaN 可能表明 real 的精度有问题。代码中是否有硬编码的实数种类？
让我们看看。该代码声明了一个巨大的整数工作数组，但随后将其分解并传递给各种子例程，其中将事物声明为实数* 8。有大量的表格查找，可能是没有正确复制出来。
@Patrick - 尝试检查保存，用特定类型声明所有类型，验证数组是否越界，然后挑选一些奇怪的值......我怀疑改变 opt.可能是原因。我以前从未遇到过这种情况。
@Patrick：英特尔 Fortran 编译器用户指南应该解释 -O2 使用哪些选项，而不是作为单个编译器选项，它是一组选项的简写。弄清楚那组是什么，然后单独使用选项来查看是否可以找出导致问题的原因，这应该会为您指明正确的方向。

【解决方案2】：

如前所述，最终结果可能对数值敏感，并且放宽算术规则的优化会导致数值不稳定。或者优化可能会暴露程序中的错误。如果代码使用内部整数数组进行自己的内存管理（Fortran 90/95/2003 不再需要），则不同的操作系统可能会出错。我会进一步调查...

我建议打开所有警告和检查选项。如果有错误并且你很幸运，他们可能会揭示它或提供线索。至少它很容易尝试。试试这些选项：

-check all -traceback -warn all -fstack-protector

您也可以尝试“-assume protect_parens”，这将使 ifort 符合 Fortran 标准，看看是否可以解决问题。

或者程序可能假设内存已预先分配给某个值。这与Linux和Mac有区别吗？我认为 ifort 可以选择控制这一点。如果它是旧的 Fortran 77 代码，它可能会假设局部变量在过程调用中被保留，即使在声明中没有使用“save”。有一个编译器选项可以使所有局部变量都像使用“保存”一样 - 看看这是否会有所不同。

【讨论】：