Skip to content
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

A very pedantic pull request #105

Merged
merged 4 commits into from
Apr 10, 2022
Merged

Conversation

marshallward
Copy link
Member

@marshallward marshallward commented Apr 7, 2022

This PR resolves several issues which were detected by GCC's -pedantic flag.

Detailed explanations of changes are in the commit logs. A summary is provided below.

  • Forward step format descriptors (x) require an explicit step count. Single steps are now explicit. (x -> 1x).
  • The no-advance descriptor ($) is not standard, and is replaced with the advance='no' argument in write()
  • All format descriptors should be separated by commas, even when implicitly distinguishable.
  • Line continuation tokens applied to strings must appear at both the endline and start of the new line.
  • A obsolescent statement function in MOM_mixedlayer_restrat has been redefined as an internal function.
  • Subprogram specification requires that variables be declared before they can appear in subsequent declarations. (e.g. real :: i0 must appear before real :: x(i0:)).
  • Assignment of 2**-31 to 0x80000000 is strictly incorrect (even if almost universally true), since variable ranges must be signed and symmetric, and this bit sequence is undefined for int32 types. This has been replaced with explicit bit manipulation via ibset().

None of these changes are particularly significant, but they will allow us to introduce the -pedantic flag in our testing, which will help to preemptively detect issues on untested compilers and platforms.

This fixes several (extremely) minor issues in the source code which
were detected as nonconformat by the `-pedantic` flag.

None are serious, and none are likely to resolve any outstanding issues.
The main benefit is that it allows us to apply the `-pedantic` flag into
our testing, which can help to detect future issues.

The issues which have been fixed are described below.

* The `nX` edit descriptor must include the number of forward steps.
  The implicit single step (`1x == x`) is a compiler extension.

* The no-advance line record write token `$` is a compiler extension
  which is not described in the standard.  Non-advancement is handled
  with the `advance='no'` argument.

* Edit descriptors in format statements must be separated by commas,
  even though many compilers will ignore missing commas if there is no
  ambiguity.

* When line continuation tokens are applied to strings, they must appear
  at both the end of the first line and the beginning of the subsequent
  line.  Most compilers do not require this second starting token.

* In function descriptions, if a variable used in the declaration of
  another variable, such as an array index, then it must be declared
  before any other variables refers to it.

  For example, this is invalid:
  ```
     function foo(i0, x)
       real :: x(i0:)
       integer :: i0
  ```
  and `i0` must be declared before `x`.
Statement functions are obsolescent in the current language standard,
and can be redefined as an internal function within a subprogram.

This patch replaces the statement function `psi` (streamfunction) in
`mixedlayer_restrat_general` as an explicit internal function.
The MOM_random generator used bit masks which were set with integer
values.  This is problematic for the sequence 0x8000 0000, because it
must be set with a value of -2**31.

In 4-byte integers, this is strictly not representable in Fortran, which
requires symmetric signed domains for its variables.  Since the upper
bound is 2**31 - 1, the lower bound must be -2**31 + 1, which is larger
than -2**31.  Any value assigned to the 0x80000000 bit sequence is
considered a noncompliant compiler extension.

The current implementation seems to resolve this by using a kind=8 value
(itself problematic, since 8-byte is not assured), but it still requires
assigning this value to a 4-byte integer which cannot (strictly)
represent the value.

This patch averts the whole issue by explicitly setting the bits, and
makes no reference to its integer value.  It leaves the compiler to
decide its interpretation.  And since the variable is only used in bit
operations, there is no ambiguity in behavior.

Note that GCC 9 does not support BOZ conversion from z'80000000' to int,
since it still expects BOZ literals to be within the bounds.  This is
why we use ibset() in place of a literal.  Later GCC versions do not
have this objection.
@codecov
Copy link

codecov bot commented Apr 7, 2022

Codecov Report

Merging #105 (d3d0c8e) into dev/gfdl (c150f37) will increase coverage by 0.00%.
The diff coverage is 3.98%.

@@            Coverage Diff            @@
##           dev/gfdl     #105   +/-   ##
=========================================
  Coverage     28.75%   28.75%           
=========================================
  Files           248      248           
  Lines         72970    72976    +6     
=========================================
+ Hits          20979    20985    +6     
  Misses        51991    51991           
Impacted Files Coverage Δ
...g_src/external/GFDL_ocean_BGC/FMS_coupler_util.F90 0.00% <ø> (ø)
...fig_src/external/GFDL_ocean_BGC/generic_tracer.F90 0.00% <ø> (ø)
src/ALE/MOM_remapping.F90 45.97% <0.00%> (ø)
src/core/MOM.F90 58.47% <0.00%> (ø)
src/core/MOM_forcing_type.F90 42.68% <0.00%> (ø)
src/core/MOM_open_boundary.F90 20.08% <0.00%> (ø)
src/diagnostics/MOM_PointAccel.F90 3.08% <0.00%> (ø)
src/diagnostics/MOM_debugging.F90 7.90% <0.00%> (ø)
src/diagnostics/MOM_sum_output.F90 62.56% <0.00%> (ø)
src/framework/MOM_diag_vkernels.F90 83.10% <0.00%> (ø)
... and 13 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c150f37...d3d0c8e. Read the comment docs.

Copy link
Member

@Hallberg-NOAA Hallberg-NOAA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that all of these changes are useful, and will help to bring MOM6 into compliance with the most restrictive versions of the MOM6 standards. This PR has passed TC testing as well as pipeline testing at https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/15196.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants