Visual studio 2012 遗留Fortran代码编译问题

我有从60年代到90年代的遗留Fortran代码，我需要能够编译这些代码

代码按照编写的方式工作，即使它使用了一些不再是标准的旧做法。 它是在英特尔Visual Fortran 2011编译器和Visual Studio 2008上成功构建的。我现在正在使用Visual Studio 2012和Intel Visual Fortran 2013。我似乎找不到合适的选项来翻转以允许它构建

主要的问题是使用了巨大的等价数组，它们通常不是将数组或实际指针传递给子例程，而是只传递指针等价数组的单个值，并且以某种方式暗示使用一个值序列。主要错误是

实际参数的类型不同于伪参数的类型 如果实际参数为标量，则伪参数应为标量，除非实际参数为字符类型，或者是非假定形状、指针或多态的数组元素

---

再一次。我知道代码在构建时确实有效。如果有任何有用的建议，我们将不胜感激。

我的问题的答案是转到“项目属性”->“诊断”->“语言使用警告”->“检查例程界面”，并将其设置为“否”。

您的查询已经过去了大约一年，但我也遇到了一个类似的问题，涉及fortran指针和动态内存分配，我能够解决这些问题

一个关键问题是，旧代码中的内存地址位置值相当于INTEGER*4数据类型，而在新操作系统中，它们是INTEGER*8。动态内存分配的工作方式是，虚拟数组“HEAPii”的位置被用作锚定点，相对于它，malloc给出的绝对地址可以被引用。如果堆基址，即LOCHEAP1是11111，并且如果malloc释放的绝对地址位于内存地址1731111，并且如果堆被分配为整数*4或等效实数*4，则malloc释放的第一个位置等效于堆1731111-11111/4+1。在子例程调用中使用HEAPiaddress作为参数，iaddress的索引值非常大，这样就可以将堆的适当部分用作被调用子例程中的数组参数

有问题的地方包括:

第1点。由malloc给出的释放内存的绝对地址的值存储在堆中存储的计算数据值之后的一个位置。这个地址值存储在那里，以便以后可以使用它来释放内存。如果此INTEGER*8地址存储在新操作系统/编译器的INTEGER*8地址寄存器的边界上，则当您尝试基于INTEGER*4堆的索引访问此存储的INTEGER*8内存地址值时，它将导致一个十六进制的厄运式崩溃。这可以通过在内存地址的这个存储值的存储点之前包含一个额外的1整数*4位置填充来避免。当前一数据段中存储的数据值数量为XXXX*4数据值的奇数时，就需要这样做。存储的内存地址值可以在需要时读取为整数*8地址，通过将INTEGER*4堆等效为INTEGER*8 LONGHEAP，并在LONGHEAP中使用一个索引值，该索引值约为堆中用作数组索引的超长索引值的1/2，使用-1和+1来解释从1开始的数组的fortran索引

第2点。需要跟踪存储内存地址位置的所有变量，并将其从整数*4切换到整数*8。这在调用函数的子例程中是很棘手的，而调用函数的子例程。。。要寻找的一种结构是内存位置的交换，TEMP=Iaddress；Iaddress=Jaddress；Jaddress=TEMP：在这种交换中，确保TEMP是整数*8。其他内存地址算法和临时存储变量也可能导致问题。此外，一旦进行了此切换，您需要检查这些新的INTEGER*8变量是否已被用作子例程和函数调用中的参数。如果是这样，您需要适当地修改被调用的函数/子例程，并确保对同一函数/子例程的所有其他调用中的数据类型一致

---

可能只需要将所有内容切换到*8并检查是否有涉及索引算法的语句，但是，我不确定新的逻辑*8值数组和旧的整数*2数组的一些奇特的东西是否会起作用。

我知道有一个航空航天安装正在通过将Fortran转换为C来处理这个问题。事实证明，如果没有Microsoft兼容的编译器支持，Fortran很难维护。我的意思是我知道我可以重写代码…Fortran编译器供应商知道向后兼容性对他们的客户很重要。我建议您就“英特尔Visual Fortran编译器for Wind”提问

---

ows论坛，并提及用于处理代码的编译器选项。他们可能会为您提供适用于IVF 2013的编译器选项。如果没有，他们甚至可能将您的问题视为bug并修复编译器。您是否与技术支持部门联系？“英特尔Visual Fortran”是一种商业产品，许可证附带支持。请与卓越支持或支持论坛联系。如果您的代码出现错误，请通过编译时警告和检查选项进行检测。如果关闭这些选项，通常不会也无法检测到这些错误。根据编译器正在识别的特定内容，您问题中的短语“不再标准”可能应该写为“从未标准”。您应该能够更改整数的默认种类值，这可能对您有所帮助。