Any chances for gfortran support?

[zmiimz]

First, thanks for this remarkable and instructive Fortran code.

I did try to compile petaca with GNU gfortran 5.2.1 (this is the most recent stable version I have without compiling trunk source code) and got many errors and compiler bugs (ICEs), mostly for sourced allocations. Nevertheless, workarounds exist for many (all?) of them. Moreover, the next gfortran version (6.0) should fix this sourced allocation, so I am wondering if you have tried and abandoned this compiler already or there are still some plans to test and to include gfortran to the supported list?

In principle, such gfortran fixes could be managed and merged into the code with combined GFORTRAN and VERSION preprocessor directives (similarly to INTEL ifort bugs)?

[Neil Carlson]

Back in september I spent some time trying to get Petaca compiled with
gfortran. I was using a "6.0" snapshot of the repository. I did manage to
work around many of the bugs using the #ifdef approach you mention, and
made several bug reports. But in the end there were several critical
issues that didn't have a feasible workaround. I forget exactly what they
all were (I'm at work now), but a big one is that gfortran can't handle
deferred-length allocatable character variables correctly. This one is a
long-standing bug (several years at least) that no one seems to to be
willing or able to fix. Even though it's not working yet, I should get my
work committed to github -- you might be able to do something with it.
I'll see if I can't do that this weekend.

Cheers, Neil

On Tue, Oct 27, 2015 at 9:44 PM, M. Zapukhlyak [e-mail]
wrote:

First, thanks for this remarkable and instructive Fortran code.

I did try to compile petaca with GNU gfortran 5.2.1 (this is the most
recent stable version I have without compiling trunk source code) and got
many errors and compiler bugs (ICEs), mostly for sourced allocations.
Nevertheless, workarounds exist for many (all?) of them. Moreover, the next
gfortran version (6.0) should fix this sourced allocation, so I am
wondering if you have tried and abandoned this compiler already or there
are still some plans to test and to include gfortran to the supported list?

In principle, such gfortran fixes could be managed and merged into the
code with combined GFORTRAN and VERSION preprocessor directives
(similarly to INTEL ifort bugs)?

—
Reply to this email directly or view it on GitHub
#1.

[zmiimz]

Yes, that would be helpful!

[Neil Carlson]

I've committed the start of support for gfortran. This consists of some cmake definitions (suggested by @certik) and some workarounds for bugs in the 5.2 compiler. The code and tests compile successfully, but 6 of 9 tests fail with the DEBUG build, and 5 of 9 with the RELEASE build. Here's a run down of the issues. (Note that the 6.0 snapshots don't provide any relief from these issues. I had tested 20150906 earlier, and 20151025 today; the latter introduced some regressions from 5.2 and was in even worse shape.)

• Warning: Only array FINAL procedures declared for derived type [...]

  There are a bunch of these warnings during compilation. They are bogus.
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175

• test_map_any_type (2) (DEBUG only)

  At line 375 of file .../src/map_any_type.F90
  Fortran runtime error: Recursive call to nonrecursive procedure '__final_map_any_type_List_item'

  This is a bogus error. I reported this as bug 67560 which was dismissed as a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67505

• test_timer_tree (9). Bad code is being generated for line 287: allocate(character(this%max_name_len)::name(n))
  See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070#c19

• test_vector_any_type (4). Finding errors in these subtests:

  • test_get_value (segfault). Traced to line 387 of parameter_entry_class.F90 allocate(value(lbound(this%value,1):ubound(this%value,1)), source=this%value)
    See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564
  • test_set_get_character (wrong results). Traced to line 494 of parameter_entry_class.F90: allocate(character(len(v)) :: value(size(v)))
    Probably same issue as 54070 above.
  • test_value_ptr (wrong results). Traced to line 374 of test_any_vector_type.F90: val => x%value_ptr()
    The result pointer inside the value_ptr function (vector_value_ptr in parameter_entry_class.F90) appears to be good, but the val pointer is bad.
  • test_assignment (wrong_results). This is another one involving allocatable deferred length character variables.

• test_matrix_any_type (5). I'm sure the issues here are precisely those encountered in test_vector_any_type.

• test_parameter_list_type (6). Initial error (there may be others) traced back to line 380 of parameter_entry_class.F90: allocate(this%value(lbound(value,1):ubound(value,1)), source=value)
  Same issue as earlier, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564

• test_secure_hash (8). The results for a scalar 128-bit real are incorrect for md5 and sha1. The results for all the other dozens of tests are correct, including tests for 128-bit real arrays. Don't know what the issue is here -- strange.

[Ondřej Čertík]

Here is my PR that makes it compile with gfortran: certik/petaca#3, but as @nncarlson reported here and in that PR, it requires some work, and I didn't have a chance to do it yet.

[zmiimz]

I see... It looks like there is no so much space left for workarounds there at this stage (taking into account your corrections and submitted bugs). But I'll give it a try.

The worst problem seems to be in polymorphic sourced allocation in set_vector_value, and probably in set_matrix_value subroutines (according to failed test_set_get_xxx in test_any_vector_type), where this%value obtains shape but not values from source=value...

[Neil Carlson]

Status update using the 20160103 snapshot of the 6.0 compiler: no apparent changes/improvements from my 11/1/2015 summary. Is no one working on GFortran anymore?

[zmiimz]

Patience is needed when it comes to gfortran development...

[Neil Carlson]

Some progress to report. Paul Richard Thomas has been working on some of the gfortran bugs over the last 1-2 months and things are looking much better, and possibly usable, with the current 6.0 svn branch (r234329). The really serious problems associated with the now closed PR54070 look to be resolved. A few minor issues from #1 (comment) remain:

• Warning: Only array FINAL procedures declared for derived type [...] There are a bunch of these warnings during compilation. They are bogus and can be ignored; see PR58175 (Debug only)
• The spurious runtime check errors thrown by -fcheck=all are still there, but I've added -fcheck=no-recursion to CMakeLists.txt to disable this check (Debug only)
• The problems associated with PR67564 (still open) remain in some of the unit tests (test_any_vector_type, test_any_matrix_type, and test_parameter_list_type), but I've worked around these by simply commenting out some parts of the tests. The petaca code itself doesn't appear to trip this bug, but it may be an issue for client code to watch out for.
• The failure of a couple of the subtests in test_secure_hash remains.

So all tests are now passing with the exception of test_secure_hash

[Ondřej Čertík]

I can confirm that gfortran 6.1.1 compiles Petaca just fine (I used the latest master 80d2a0d), and all tests pass, except fortran_dynamic_loader, secure_hash, timer_tree. Here is the log of the build that works for me: https://gitlab.com/certik/petaca/builds/3285839

[Neil Carlson]

There was a brief flurry of gfortran bug fixes (mostly by Paul Thomas) after 8.1.0 was released, and wonder of wonders, Petaca now compiles and passes all tests (no workarounds either)! The fixes were also back ported to the 7.3 branch. Here's what works:

• 7.3.1 (20180516) and presumably later
• 8.1.1 (20180521) and presumably later

Versions 7.3.0 and 8.1.0 and earlier do not work.

I'm going to go ahead and close this (finally!)