gfortran写和格式不需要符合intel编译器

我正在编译一个已知与ifort使用gfortran编译的程序。gfortran写和格式不需要符合intel编译器

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)

：但是，编译器就行了

WRITE (11,1325) ((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

来源

2013-04-29 dmon

非常有趣的问题。它仅适用于数组：

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-29 15:00:22

你好弗拉基米尔！感谢您快速发表的评论。是的，这是我第一次详细地介绍Fortran，在我看来，对于一种成熟的语言来说，有一种奇怪的怪癖。 – dmon 2013-04-29 15:14:13

正如其他人近期发布的类似问题一样，由于其传统，英特尔编译器默认允许多个扩展。如果您提供了相应的标准检查选项（例如Windows上的/stand），编译器将发出诊断信息。

我不知道这个特定扩展名的具体来源，但它涵盖了几分偶然语法的误解，在这里，人们把“论据”来写或读括号“功能” ......

READ (*,*) (not_valid_syntax)

（在写声明括号表达式本身就是一种表达，这是一个有效输出列表项 - 几年前，英特尔编译器会得到一个有点困惑的是。）再次

来源

2013-04-29 20:49:48 IanH

干杯伊恩，是的，它似乎是旧的FORTRAN和另一种新的编译器的组合引发了一些怪癖。作为一名非FORTRAN程序员，我开始明白为什么尽管速度很快就失宠了。 – dmon 2013-05-01 10:39:50

您的原始代码不是，也不是“真实的”Fortran，如任何Fortran标准中定义的那样。它使用编译器特定的扩展。当您更改编译器时，使用标准语言的扩展可能会导致问题，这几乎不是Fortran特定的问题。编译器之间的可移植性是标准存在的原因 - 如果程序员不遵守它们，他们将得到他们应得的。 – IanH 2013-05-01 11:13:35

gfortran写和格式不需要符合intel编译器

回答

相关问题