是程序自身的问题。

参数 STIFC 的实参和虚参类型不匹配。

你自己的标题里不是都写得很清楚了么？

下面是我从网上复制过来的，他的解释如下。
This is a very bothering error, which is not your own fault. It's just because someone else write the code with different version. To solve this problem, just change your project property from debugging to release. Then build it and run it!
可是我按release运行后，也还是出现这样的错误。
网上有人说以前的老程序中都是用common，现在新版本的程序建议不再使用common，而是以module代替，不知这样能不能行？

一个很简单的问题，你干嘛非得想那么复杂呢？

网上的说法不一定就是你遇到的问题。

世间的问题往往不是很简单的一个问题一个方案这样简单的。

就是 STIFC 这个变量，虚参和实参类型不一致嘛。

你的标题说得很清楚，为什么帖子内容却相信另一种方案呢？？

你仔细检查一下这个变量，就是 STIFC，第 1322 行。虚参是什么类型，实参又是什么类型？是不是不一致，如果不一致应该是什么？

要么改实参，要么改虚参，反正改得一致就好了。

这是很简单，很常见的一个错误。干嘛要搞那么复杂呢？

这个程序是别人给我的，他们以前是可以运行的，这样程序本身不会有问题。程序先使用common语句定义了一些变量，并将他们保存为一个.fh的文件。在主程序和各个子程序中都   include该fh文件，这样虚参和实参的类型是一样的。

不同编译器对语法的检查严格程度不同。

某些编译器可能默许某些错误的存在。

请注意：编译器允许你编译，并且编译成功。绝对不等于 你的代码是完善的！！

事实上，很少有人敢保证自己的代码是完全符合语法的。很多很多能够正常跑出结果的代码，都隐含很多可能出错的地方。以致于更换编译器或者更换操作系统重新编译时，不得不或多或少的进行修改。这是非常普遍的现象。

common 语句已经过时了，强烈建议不要使用。

而且 common 只是简单的1个字节1个字节的对应。并不干涉变量的类型。

换句话说，common 就是一个名字的对应，不管这些变量的类型。

比如，同样是
common /a/

在主程序里，a 可以是整型，比如 a = 31
而在某个子程序里，a 可以是字符型，实型，等等等等。这两个变量就是占用同一个内存空间，并不保证是同样的数据类型。

这样的特征使得 common 变得非常的不稳定，不可靠，容易出错。

正因为如此，新的语法特征已经明确指出抛弃 common 语法。

正如你之前自己提到的那样，新的代码建议使用 module 代替 common。

但你已有的程序可能修改起来很麻烦，但是你应该对此了解。

强调一次，[color=red]仔细检查 STIFC！！！！！变量不能只在 common 中出现，必须明确定义其类型，精度！！！！[/color]

编译器给你的信息是很清晰很明确的，就是这个变量类型不符。

我不明白为什么你摆着这么明确的线索不用。

你好，这是别人给我的早期程序。我又看了一遍，觉得问题可能是这样的：
在主函数中首先要求了一块内存空间， 
COMMON A(50000)
REAL*4 A
然后，N1=1
N2=10
N3=16
...
NUM=3
NUM2=2
调用子函数的语句为 CALL TEST1(A(N1),A(N2),A(N3))

子函数为
subroutine TEST1(ID,IT,IY)
DIMENSION ID(NUM*NUM),IT(NUM*NUM2) IY(5)
...
ENDSUBROUTINE

实参和虚参使用同样的内存空间，但是实参是一维数组，虚参是二维数组，数组下标不一致，所以就出现了变量不匹配的问题。

非也非也，实参 A(N1) , A(N2) , A(N3) 都是 real 的单变量，不是数组！！！！

虚参 ID  , IT , IY 都是一维数组。

这同样是不正确的用法。

你的代码错误太多了。完全无法让人理解。