Implicit saves (https://fortran-lang.org/learn/quickstart/gotchas/#implied-save) is a gotcha in Fortran that can lead to unintended behavior. Writing something like integer :: c=0 is a one-shot initialization, where subsequent calls of the function will actually remember the variable value if changed.
As a first pass at identifying possible issues, I am looking for one-shot declarations using:
grep -v "parameter" */*/*f90 | grep "::.*=" | grep -v pointer | grep -v save
These can be solved by adding an explicit save or parameter keyword when needed. Or, if the variable should not be saved, then set its value in a new line.
So far, I've just added some obvious parameter keywords. In the future we can detect possible issues with compiler flags, but just want to clean up obvious fixes first. There should not be an impact on the code results.
There is also the issue that 1_dp and 1.0_dp are not the same thing in Fortran (see: https://fortran-lang.org/learn/quickstart/gotchas/#floating-point-literal-constants-again). The former actually becomes a integer literal constant, and can have the wrong consequences if we are using them to compute real numbers. So I made a few changes in the code fixing these. It should not have an effect because the issue usually shows up when you are composing 2 of these integer literal constants, but is better practice to have the .0_dp added
Implicit saves(https://fortran-lang.org/learn/quickstart/gotchas/#implied-save) is a gotcha in Fortran that can lead to unintended behavior. Writing something likeinteger :: c=0is a one-shot initialization, where subsequent calls of the function will actually remember the variable value if changed.As a first pass at identifying possible issues, I am looking for one-shot declarations using:
grep -v "parameter" */*/*f90 | grep "::.*=" | grep -v pointer | grep -v saveThese can be solved by adding an explicit
saveorparameterkeyword when needed. Or, if the variable should not be saved, then set its value in a new line.So far, I've just added some obvious parameter keywords. In the future we can detect possible issues with compiler flags, but just want to clean up obvious fixes first. There should not be an impact on the code results.
There is also the issue that
1_dpand1.0_dpare not the same thing in Fortran (see: https://fortran-lang.org/learn/quickstart/gotchas/#floating-point-literal-constants-again). The former actually becomes a integer literal constant, and can have the wrong consequences if we are using them to compute real numbers. So I made a few changes in the code fixing these. It should not have an effect because the issue usually shows up when you are composing 2 of these integer literal constants, but is better practice to have the.0_dpadded