2

我正在编译一个已知可以ifort使用 using编译的程序gfortran。但是编译失败就行了

WRITE (11,1325) ((IFILE,FILENAME(IFILE)),IFILE=1,IFILES)

编译错误：

main_file.f:205.32:

     WRITE (11,1325) ((IFILE,FILENAME(IFILE)),IFILE=1,IFILES)       
                            1
Error: Expected PARAMETER symbol in complex constant at (1)
make: *** [main_file.o] Error 1

将此行更改为（注意删除“（”和“）”）

WRITE (11,1480) (IFILE,FILENAME(IFILE),IFILE=1,IFILES)

匹配下一行

1480      FORMAT (1X,I1,' ',A40)

解决了这个问题，但我想知道是否有人知道为什么英特尔编译器没有捕获这个错误。在这种情况下，似乎gfortran哪个给出了正确的行为。我的编译标志是：

gfortran -fno-automatic -mcmodel=medium -O2 -ffast-math  main_file.o -o main_file
4

2 回答 2

1

正如其他人在最近的类似问题中所发布的那样，由于英特尔编译器的传统，默认情况下允许许多扩展。/stand如果您提供适当的标准检查选项（例如在 Windows 上），编译器将发出诊断信息。

我不确定这个特定扩展的具体来源，但它涵盖了一些偶尔的语法误解，人们会将“参数”放在括号中写入或读取“函数”......

READ (*,*) (not_valid_syntax)

（在写入语句中，括号中的表达式本身就是一个表达式，这是一个有效的输出列表项 - 几年前英特尔编译器会对此感到有些困惑。）

于 2013-04-29T20:49:48.953 回答
0

相当有趣的问题。它仅适用于数组：

 print *, ((1,["a","b"]),i=1,10)
end

有效，但是

 print *, ((1,"a"),i=1,10)
end

ifort 失败：

: error #6063: An INTEGER or REAL data type is required in this context.   ['a']
 print *, ((1,"a"),i=1,10)

天知道解析器在第一个工作案例中认为它是什么，也许是一个不完整的嵌套暗示呢？肯定它不是合法的 Fortran 语法，应该被需要标准 Fortran 的编译器拒绝。英特尔可能有理由接受这种语法。

于 2013-04-29T15:00:22.400 回答