Adrian, I goggled a bit but couldn't understand anything I found. My guess is that
type(*) doesn't work for certain derived types (why not?) perhaps those that contain procedures. If I remove the procedure from the routine it all compiles, thus producing some evidence my theory is correct. So we have a problem. The type checking one user wants is causing another users code to not build. Here is a short term fix you can do. After you run ./configure edit $PETSC_ARCH/include/petscconf.h locate #ifndef PETSC_HAVE_FORTRAN_TYPE_STAR #define PETSC_HAVE_FORTRAN_TYPE_STAR 1 #endif then run make. This will turn off the type checking for all routines that have type(*) arguments which includes SNESSetConvergenceTest I don't have a good long term solution at the moment. Maybe a Fortran expert has some idea. Barry > On Oct 18, 2018, at 10:14 PM, Adrian Croucher <[email protected]> > wrote: > > hi Barry, > > On 18/10/18 11:34 AM, Smith, Barry F. wrote: >> Sorry about this problem. I think the change was only introduced in >> master and should not affect 3.10.x Please confirm that master is where the >> failed compile is? > > Yes, it's on master. I have tracked down the commit at which it started to > fail: 6f222c9d1e, "type checking for Fortran" (Fri Sep 28). > >> Please send us the calling sequence of your routine that won't compile >> (cut and paste). > > I've attached a minimal example program which fails with the following error: > > call SNESSetConvergenceTest(snes, convergence, context, & > 1 > Error: Actual argument at (1) to assumed-type dummy is of derived type with > type-bound or FINAL procedures > > Cheers, Adrian > >>> On Oct 17, 2018, at 5:21 PM, Adrian Croucher <[email protected]> >>> wrote: >>> >>> hi >>> >>> A colleague has just reported that my code no longer builds with PETSc >>> 3.10.2, though it builds OK with 3.10.1. >>> >>> The problem appears to be the Fortran interface to >>> SNESSetConvergenceTest(), which was changed at commit f9a1a4d. >>> >>> It now complains about the context argument we are passing in to this >>> function ('cctx' in the interface, which is declared there as type(*)). The >>> error is: >>> >>> "Error: Actual argument at (1) to assumed-type dummy is of derived type >>> with type-bound or FINAL procedures" >>> >>> This is true, the argument being passed in is of derived type with >>> type-bound procedures. Previously this didn't bother it, but it looks like >>> it does now. >>> >>> Is its complaint legitimate? or perhaps a compiler bug? (this is using gcc >>> 6.3.0) >>> >>> - Adrian >>> > -- > Dr Adrian Croucher > Senior Research Fellow > Department of Engineering Science > University of Auckland, New Zealand > email: [email protected] > tel: +64 (0)9 923 4611 > > <test_snes.F90>
test_snes.F90
Description: test_snes.F90
