ifort和gnu fortran之间fortran格式的差异

据我所知，我目前正在编写一段代码，可以很好地使用ifort进行编译。 我试图用gfortran编译它，但出现以下错误：

我被这个格式弄糊涂了：8ES18.10E，最后一个E是什么意思？ 这是ifort/gfortran不兼容吗

---

感谢您的建议

ifort将WRITE（100'（8ES18.10E'）解释为WRITE（100'（8ES18.10E2）），至少在我发现的示例中，

不确定，但可能格式中的第二个

E

不应该出现。我认为gfortran拒绝在最后的

E

后面没有一个或两个数字的格式是正确的。英特尔Fortran并没有拒绝它，这并不奇怪，它只是一系列编译器的最新版本，可以追溯到60年代。在此过程中，它获得了许许多多的非标准特性（或不再是标准的特性），并通过对向后兼容性的无限热情，没有放弃任何一个特性，尽管明智地使用标志可以说服它在这方面更加无情，以及为什么gfortran正确地拒绝了它

18

是格式化数字的总宽度

10

是小数点后的位数。尾随的

E

需要一个整数值来指定指数中的位数。正如@HighPerformanceMark所述，英特尔正在接受Fortran标准的扩展。英特尔提供了一个请求符合Fortran标准的选项（参见其文档）。与其说ifort接受它作为扩展

ES18.10E

，不如说它没有义务告诉您

ES18.10E

不是一个有效的格式项。上面所有的评论都很贴切，除了它不能被认为是一个扩展，因为它毫无意义。至于ifort在运行时对无效格式做了什么，我的猜测是尾部的E将被忽略，但这需要在每个主要版本中进行测试。如果不可能进行检查，这是令人失望的，并且问题报告是合理的。在ifort中检查的任何级别的标准都应要求符合f95。正如francescalus所指出的，Fortran标准并不要求能够检查所有方面的合规性。

WRITE(100, '(8ES18.10E)') a
1 Error: Positive exponent width required in format string at (1)