Comments (10)
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
from petaca.
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!)
from petaca.
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 [email protected]
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.
from petaca.
Yes, that would be helpful!
from petaca.
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_get_value (segfault). Traced to line 387 of parameter_entry_class.F90
-
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.
from petaca.
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.
from petaca.
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...
from petaca.
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?
from petaca.
Patience is needed when it comes to gfortran development...
from petaca.
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
from petaca.
Related Issues (20)
- Is timer_tree::stop error return needed?
- User-specified kinds when creating parameter lists from JSON text
- JSON input of arrays of parameter lists
- "set" procedure not accepting input of parameter_list type HOT 5
- gfortran 8.3.1 fails any_matrix_type test HOT 10
- gfortran 8.3.1 fails parameter_list_type test HOT 3
- Compiling with the flang compiler HOT 1
- Use JSONPath style syntax for parameter list names HOT 2
- Parameter list methods return allocated 0-length errmsg when stat==0
- Intel 19 regression HOT 1
- Intel 19.1 regression HOT 1
- Test failures on Mac w/NAG HOT 1
- GCC 9+ loses dynamic type for non-scalar parameters in parameter list HOT 1
- Error message is not returned correctly by gfortran 9+ HOT 10
- version tag HOT 2
- Error in Intel compiler workaround in parameter_list_json HOT 1
- Unit tests for parameter_list_json HOT 1
- TYPE_IS inquiry methods for parameter list
- Report INTEL_BUG20140921 HOT 1
- Replace CALL EXIT with standard STOP
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from petaca.