bob*_*nto 5 io fortran intel-fortran
我正在处理的 Fortran 代码有几行类似于
WRITE(filename, '(A16,"_",I4,".dat")') filename, indx
Run Code Online (Sandbox Code Playgroud)
该代码已在许多不同的平台和几乎所有主要编译器上成功编译并运行了数百次。但突然间,最新的(或者,无论如何,新的)英特尔编译器不喜欢它了。它给出警告信息"forrtl: .... Internal file write-to-self; undefined results"。该行执行后,"filename"原本合理的字符数组变为空白。
我想问题在于它既filename是写入的输入又是内部写入的目的地。修复很容易。它可以将filename目的地替换为类似的东西filename_tmp。但正如我所说,到目前为止,这从来都没有必要。
所以我想知道,文件名作为输入和目标是否违反了 Fortran 标准,但这些年来所有这些编译器都对此视而不见,而现在英特尔变得越来越严格?还是英特尔太“势利”了?还是彻头彻尾的越野车?
问题陈述的执行1始终被明确禁止。write
我们目前看到(F2018 12.6.4.5.1 p7):
在执行指定内部文件的输出语句期间,该内部文件的任何部分都不得因评估任何输出列表项的结果而被引用、定义或变为未定义。
filename是一个内部文件,输出列表项的评估filename是对该内部文件的引用。
这不是编译器需要检测的编程违规,因此您可以根据需要将其视为编译器改进的诊断能力/挑剔的情况。Fortran 程序不会因编译器的这种行为变化而受到损害。
当然,Fortran 66 没有内部文件(或字符类型),而 Fortran 77、90 和 95 使用不同的单词来达到相同的效果(例如,参见 F90 9.4.4):
如果指定了内部文件,则输入/输出列表项不得位于该文件中或与该文件关联。
如果看起来限制性更强,从 Fortran 2003 开始,输入和输出语句的限制是分开声明的(上面只引用了输出,p8 表示输入)。
1注意执行的使用:语句本身作为语句并没有什么问题。它允许存在于未到达的源代码中。编译时检查这条语句并不是一件简单的事情。
| 归档时间: |
|
| 查看次数: |
657 次 |
| 最近记录: |