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編譯器

回答

相關問題