hi Thanks to you both for looking into this.
It sounds like if we want type checking in the PETSc Fortran interfaces, which I agree is a useful thing, then no compilers are going to support passing in these derived types with type-bound procedures via type(*) interfaces anytime soon.
In my case the derived-type objects I'm passing in to SNESSetConvergenceTest() don't really need to have type-bound procedures (the derived type doesn't get subclassed, and there aren't really any data-hiding considerations), it's mostly just a style thing so that they work similarly to other derived types in the code. So I could fairly easily just turn the type-bound procedures into ordinary subroutines, not bound to any derived type.
That might be the simplest fix for me. I suppose this issue could still affect other people, but maybe not a lot of people are using PETSc with F2003.
- Adrian On 23/10/18 2:55 AM, Martin Diehl wrote:
I'm sorry, I don't understand. Are you saying that the example code is not correct Fortran?In the case that your interface has a type(*) argument, it is not valid Fortran because 'context_type' contains the type-bound procedure 'context_init'. That is why the GNU compiler complains when the interface exists. Apparently, without the interface it accepts it, so not having an interface would be a solution in that case. However, the Intel compiler will fail during linking with or without interface, so it does not seem to be a general solution. At the moment, I believe that one simply has to live with the limitations that type(*) imposes on the data that can be passed to void*. To clarify this, I opened a thread in the Intel developer zone and will keep you updated https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744
-- Dr Adrian Croucher Senior Research Fellow Department of Engineering Science University of Auckland, New Zealand email: [email protected] tel: +64 (0)9 923 4611
