Support gfortran 10+

[akrherz]

Whilst compiling GEMPAK on rhel9, I found this necessary:

-FOPT = -fno-stack-protector -fno-second-underscore -fno-range-check -fd-lines-as-comments $(GEMINC) $(PYINC) -g -O
+FOPT = -fallow-invalid-boz -fallow-argument-mismatch -fno-stack-protector -fno-second-underscore -fno-range-check -fd-lines-as-comments $(GEMINC) $(PYINC) -g -O

I need to research this some more before adding it as the default here.

[akrherz]

An example build Error without those flags set:

gdplot.f:788:38:

  707 |      +                                                        fi, fj, s,
      |                                                              2    
......
  788 |                                         CALL GARRW ( 'N', 1, x01, yyy,
      |                                                                  1
Error: Rank mismatch between actual argument at (1) and actual argument at (2) (rank-1 and scalar)
make: *** [Makefile:87: gdplot] Error 1

Boggling what I am up for doing with this :)

[sgdecker]

You may have seen this already, but the argument mismatch change is discussed in the GCC porting guide.

[akrherz]

Thanks @sgdecker , but for the example error, do you know what code fix would correct the problem? I couldn't figure it out

[sgdecker]

Here's my analysis. The 1 and 2 are pointing at the thrid and fourth arguments, so it is a little unclear, but I think both have an issue. Around line 706, the subroutine GARRW is called as follows (condensed to one line):

       CALL GARRW  ( 'G', npts, fi, fj, s, d, ier )

Later, the same subroutine is called as follows (line 788):

        CALL GARRW ( 'N', 1, x01, yyy, spd, dir, iret )

At line 121, we have the declaration:

	REAL		fi ( 100 ), fj ( 100 )

Neither x01 nor yyy are explicitly declared, so they are implicitly scalar reals. gfortran detects that the same subroutine is being called, but in one place there are real arrays (of dimension 100) as arguments, whereas in the other place the same arguments are real scalars. It is not possible (according to the language standard) for both calls to be correct, generating the error.

The fix would then depend on how GARRW is defined. Looking at appl/plot/garrw.f we have:

	SUBROUTINE GARRW ( sys, np, x, y, spd, dir, iret )
	CHARACTER*(*)	sys
	REAL		x (*), y (*), spd (*), dir (*)

so the third and fourth arguments are indeed supposed to be arrays (of arbitrary size).

Thus, the code in gdplot.f is following the typical nonstandard convention of passing a scalar variable when it would be more correct to pass an array of size one.

For this case, since x and y are input arguments in GARRW, the easiest fix would be to put x01 and yyy in square brackets in line 788:

				        CALL GARRW ( 'N', 1, [x01], [yyy],

corresponding to the very end of the porting guide. This is completely untested, but I think that would eliminate the error and be equivalent to what the non-standard code intends to do.

[akrherz]

Thanks @sgdecker, this worked:

diff --git a/gempak/source/programs/gd/gdplot/gdplot.f b/gempak/source/programs/gd/gdplot/gdplot.f
index e1a34745..5f9833e3 100644
--- a/gempak/source/programs/gd/gdplot/gdplot.f
+++ b/gempak/source/programs/gd/gdplot/gdplot.f
@@ -785,8 +785,9 @@ C
      +                                               ier)
                                        offset = FLOAT ( lenaro + 1 )
                                        x01 = x01 + offset * rwc
-                                       CALL GARRW ( 'N', 1, x01, yyy,
-     +                                              spd, dir, iret )
+                                       CALL GARRW ( 'N', 1, [x01],
+     +                                              [yyy],
+     +                                              [spd], [dir], iret )
                                    END IF
                                END IF
                            END IF

Gonna ask upstream about this.

[akrherz]

Here are my current thoughts on this situation.

• It is unclear if NCEP will update GEMPAK to formally support RHEL 9 (thus gcc 10), so I am hesitant to add a code patch that would perhaps conflict with future NCEP updates.
• I am also, by no means, a FORTRAN programmer, so adding such a change would make me nervous.
• Updating the default compile flags would be the least intrusive change here, but I have yet to get the mental clarity to understand the interplay between the various components of the build system.