I’m using 18.4CE. I have some code that is being compiled with the -Msave option and contains explicit recursive subroutines. The compiler makes all local variables static, as if they were declared with a SAVE attribute. This behavior causes recursive subroutines to fail.
The gfortran, Intel, Absoft and Sun compiliers do not make local variables static when the equivalent -Msave option is specified AND the routine is declared to be recursive.
Is this the desired behavior of the -Msave and recursive subroutines?
I’ll talk with our compiler architecture folks about this since I’m not sure what overall impact such a change would have. However, I would like to understand why your program needs -Msave?
-Msave instructs the compiler to assume that all local variables are subject to the SAVE statement. As such, it’s working as documented.
Though, -Msave is mostly intended for use with older Fortran programs and can have an adverse impact on performance. Maybe it would be better for you to explicitly add the SAVE attribute to the variables that need it, thus reducing this performance impact and not relying on compiler specific behavior?
The simulation code was first released back in 1978, so that fits in the older software category. The -Msave option has been part of the complier flags ever since 2000 when I started working with the code.
The bigger picture is that recursive routines require a new set of locals for each call, except for any explicitly SAVEd ones, in order to behave properly. The PGI compiler seems to be the outlier in the way -Msave option and recursive subroutines interact.
The simulation code was first released back in 1978, so that fits in the older software category.
Yes, it certainly does!
I put in a feature request (TPR#26714) requesting that implicit SAVE attributes not be applied to local variables of a recursive routine. It certainly make sense to do this, but will need input from our compiler folks as to the overall impact such a change would have.