-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fortran 2023 compliance and testing #723
Conversation
Adding null read operations so that compilers will not warn about unused input variables in dummy functions.
This is a minor patch which allows the code to be compiled under F2023 standardization. * Arguments are declared in the order that they are used. In this case, it means that array lengths are declared before the arrays using them. * The syntax of various IO statements has been cleaned up.
Some functions in the FMS cap used arguments which depended on other arguments, which were declared out of order. * ocean_model_data2D_get * ocean_model_get_UV_surf This patch moves the array index size definitions before the array definitions. This is required for language standard compliance.
This patch enables Fortran 2018 standard compliance testing. We could do 2023, but our current CI of choice doesn't yet have a compiler which can do this. The actual content of this PR is a decoupling of FCFLAGS_DEBUG and FCFLAGS_FMS. There is now a default FCFLAGS macro which is used by the other two macros. One can now optionally configure FCFLAGS_DEBUG without worrying about the impact on FCFLAGS_FMS. The motivation here is that we don't want to test for F2018/2023 compliance in FMS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with most of these changes, but I am a bit confused by the changes in posix.F90, in which a read
call is made for several otherwise unused intent(in)
variables after the error stop
calls.
The new read
calls will never be reached, so in some sense what they do is irrelevant, but what I am wondering about is whether some compilers might object to doing read
calls that would change the values of these intent(in)
variables. I have spent some time reading in detail about the meaning of intent(in)
, and it looks to me like this should be illegal. Is there some other fake operation that we could do with these variables (e.g., call write
instead of read
) that would be more consistent with the declared intent of these variables?
When no IO control data is specified with Obviously it's a dumb construct and I wish there were a better way to handle it, but I don't believe it will be a problem. |
Thanks for that explanation about how |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all looks reasonable to me.
Gaea regression: https://gitlab.gfdl.noaa.gov/ogrp/mom6ci/MOM6/-/pipelines/24907 ✔️ |
This PR contains several commits to ensure Fortran 2023 compliance.
Most changes are related to missing or redundant commas in I/O statements. Others were related to the ordering of input-dependent arguments in functions.
This should help improve support on other compilers which have more strict I/O syntax requirements. It will also help prepare us to turn on additional warnings and improve the overall testing of the model.
It also includes modifications to the GitHub CI to provide F2018 testing. (Unfortunately our compiler of choice is a bit out of day and cannot yet provide 2023 compliance testing.)