Fortran程序中无意义的dummy call为何会影响程序运行结果？

核心可能成因 #

• 未初始化的SAVE属性局部变量
  这是Fortran开发中最高发的此类问题诱因：如果read_parameters子例程内存在声明时直接赋值的局部变量（如integer :: read_flag = 0），Fortran会默认给该变量加上SAVE属性，仅在程序启动时初始化一次，后续调用会保留上一次的运行值。如果该变量作为读取流程的控制标志，第一次调用时可能因初始值不符合预期导致读取错误，第二次dummy调用时该变量已经被赋值为合法值，后续所有调用就都正常。
• 未显式初始化的局部变量
  如果子例程内的控制变量、计数器没有显式初始化，第一次调用时会读取栈/静态存储区的随机脏值，触发异常逻辑；第一次调用结束后该内存地址已经被写入合法值，后续调用就会正常运行。dummy调用相当于提前完成了第一次脏值覆盖的过程。
• IO状态/文件操作异常
  如果read_parameters内的文件操作没有显式检查IO状态、未正确关闭文件句柄，或使用了全局复用的文件单元号，第一次调用可能触发遗留的IO错误状态导致读取失败，第二次调用时自动清空了错误状态，后续流程就恢复正常。
• 数组越界导致的内存污染
  如果read_parameters或前置逻辑存在数组越界写操作，第一次调用时意外修改了parameter_array或控制逻辑的内存值，加入dummy调用后，新申请的parameter_array2刚好占用了之前被污染的内存地址，相当于意外修复了内存污染的影响。
• 内存布局变化掩盖未定义行为
  额外的dummy调用会改变程序运行时的栈帧结构、变量内存地址，原本会触发异常的非法内存访问刚好指向了合法的内存区域，隐藏了原本的未定义行为。

排查方案 #

• 所有代码头部强制加implicit none，禁止隐式类型声明，避免因变量类型隐式推导导致的大小不匹配、传参错误。
• 开启编译检查选项：gfortran编译时加-Wall -fcheck=all -fbacktrace -Og，ifort编译时加-check all -warn all -O0 -traceback，运行时会直接捕获未初始化变量访问、数组越界、IO错误等问题。
• 检查read_parameters内所有局部变量的声明，移除不必要的SAVE属性，所有控制变量、计数器在子例程入口处显式赋值初始化。
• 给所有IO操作增加iostat参数检查，文件读取完成后显式关闭文件单元，确认文件单元号没有全局复用冲突。
• 显式声明所有数组的维度、大小，传参时确认调用方和被调用方的数组长度匹配。

内容的提问来源于stack exchange，提问作者stepheba