Problem compiling ropp_io_init with GFortran

[Dave Offiler]

gfc make of ropp_io generates errors compiling ropp_io_init.f90 thus:

 In file ../ropp/ropp_io_init.f90:139

  use ropp_io, not_this => ropp_io_init_l1atype
                                              1
Error: Name 'isinrange' at (1) is an ambiguous reference to 'isinrange' from module 'arrays'

...repeated for all similar lines in ropp_io_init.f90.

Within ropp_io.f90:

  interface isinrange
     function ropp_io_isinrangeDT7(dt) result(inrange)
       use ropp_io_types
       type(DT7type), intent(in) :: dt
       logical                   :: inrange
     end function ropp_io_isinrangeDT7
  end interface

This, presumably, is meant to overload isinrange defined in ropp_tools/arrays/isinrange.f95 While other (LInux at least) compilers don't mind, gfc clearly doesn't like doing this.

Possible work arounds might be:

1) transfer the ropp_io isinrange into the ropp_tools version (but then the type definitions for DT would have to be moved too)

2) Don't overload isinrange, but name the ropp_io version to something else (e.g. isdtinrange). Calls to isinrange with DT7-type arguments would need to be similarly renamed.

3) Do nothing and hope that GFortran eventually allows this extra overloading (maybe reporting a simplified case via GCC-Bugzilla). Don't hold your breath on an early fix; meanwhile GFortran is not supportable.

Which way to go? [Personally, I favour a simple quick(est) fix rather than cleverness, so I would go for (2)]

[Dave Offiler]

Looked at possibility (1) and rejected it as not a straightforward changes, as the f90 code is generated from an m4 template. So taking possibility (2)...

a) ropp_io.f90

interface name changed from isinrange to isroppinrange

b) ropp_io_isinrange.f90

Comments updated to reflect new name and to break link with generic routine isinrange in ropp_tools

c) ropp_io_write_netcdf_put.f90

Changed call to isinrange to isroppinrange when checking date & time prior to writing to netCDF file.

Checked compile with gfc & ifc - ok. Tested with tests\t_ropp2ropp - ok (and checked for correct date)

Can't find any other references to isinrange in ropp_fm or ropp_1dvar, but if there are any which check the DT7 date/time type, the name will need to be changed there too.

[marq]

Could you please revert this change? As you correctly spotted, the idea is to overload the isinrange set of methods, and I do intend to add a few more, actually. This is ok in the Fortran 90 standard; if the gfc doesn't support it, it has a bug which needs to be fixed. I don't see a point in working around compiler bugs, especially if it is the only one having that problems.

Thanks.

[marq]

I've googled a bit. The same problem was reported about a year ago for lapack, see, e.g. in a ​lapack developer forum. Again, I think we shouldn't work around compiler bugs.

How recent is the version of gfortran you are using? It did have lots of development, so I would ike to know what the most recent version does in this case.

[Dave Offiler]

This was (at the time) the latest build of GFortran. (I update g95, gfc & hpg95 roughtly monthly in the sa_app space. Nevertheless, in my experience, while the build date appears to change regularly, actual bug fixes seem to be collected togther & rolled out not more than 6-monthly).

The lapack forum hints at the same issue, but then runs out of steam wihtout any conclusion. One would have to look through the GFortran Bugzilla logs to see if it was ever raised there, and if so, what the outcome.

GFortran obviously support routine overloading, since it's used throughout ROPP. The problem seems to be that it only supports overloading within the same interfce block, and not in quite seperate code files (in our case in completely different ropp modules). That seems sensible to me! I suspect the GFortran developmers would not consider this to be a 'bug', and I'm not 100% that this 'feature' (ie split across interfaces) is explicitly part of the f90 standard, but may be one of those grey areas that are open to interpretation (and hence should not be relied upon).

The long-term 'fix' (and to my mind better coding practice anyway) would be to implement (1) in my list of options. This has the advantage of eveything being togther and hence more easily traced and maintained, and where all future/new overloading of this routine should be collected. The fact that the ropp_tools interface is auto-generated means that this option is not trivial unless the m4 is disabled/removed and the interface fixed for manual editing.

Meanwhile, this ticket can be left open as a reminder to be fixed before Milestone, as nothing is broken by leaving the first change in place for beta 0.9. At this point (up to release of ROPP-1), no new routines should need to be introduced.

[Huw Lewis]

ROPP v1.1 testing passes for g95 and gfc compilers. Ticket closed as no further investigation intended.

[(none)]

Milestone 1.1 deleted