为什么xlf和ifort在数组边界读取上采取不同的方式？
为什么xlf和ifort在数组边界读取上采取不同的方式？
提问于 2012-11-10 02:16:04
我正在尝试将一段代码从ifort编译器移植到ibm xlf编译器。它在redhat上的ifort下工作得很好，但在AIX系统上的xlf下给出的结果包含"NaNQ“。结果是有一个数组边界读取了这个问题的代码开销，下面是一个简化的例子：
program main
implicit none
real(8)::a(1,0:10)=0.D0
print *, a(1,-1)
end program main 使用这两个编译器，我可以成功地编译它，没有任何错误或警告。在ifort上我得到的结果是：
0.000000000000000E+000但是在xlf上，我得到了：
0.247032822920623272E-322但是，如果我在边界之外阅读更多内容，xlf将不会编译，但我会成功编译。
program main
implicit none
real(8)::a(1,0:10)=0.D0
print *, a(1,-3:-1)
end program main在ifort上我得到：
0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000在xlf上它不能编译：
"1.f90", line 5.9: 1516-023 (S) Subscript is out of bounds.
** main === End of Compilation 1 ===
1501-511 Compilation failed for file 1.f90.为什么ifort和xlf在这个跨边界读取上采取不同的方式？有没有办法让编译器严格检查它，并防止发生跨境读取？毕竟，我花了很长时间才在我们的代码中发现了这个bug，因为我们团队已经使用这个代码超过15年了，在ifort上没有任何问题。谢谢。
回答 1
Stack Overflow用户
回答已采纳
发布于 2012-11-10 02:26:55
大多数Fortran编译器都有在运行时检查数组边界错误的选项。在这些使用常量索引的示例中，可以在编译时发现错误，这是一些编译器而不是其他编译器在不使用非默认选项的情况下所做的。对于ifort，使用-check边界来请求数组边界检查。您可以使用-check all获得额外的检查。这些选项通常不是默认选项，因为存在运行时成本。但是得到错误答案的代价可能要高得多！我发现运行时成本经常出人意料地低，并建议在代码开发期间使用运行时检查，如果运行时成本是可接受的，甚至在生产中也是如此。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/13313703
复制相关文章
相似问题
腾讯云开发者
