Hi, some more information on this topic.
First, Adrians code is not wrong. The statement on the IBM homepage regarding type(*) and type-bound procedures is according to my current understanding simply not true. However, type(*) is a feature of Fortran 2018, a standard that is not even published. My information mainly comes from the Intel developer zone, see https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744 and I have also informed the GCC/gfortran developers, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87707. I hope to get some more information in the next day and will keep you updated. best regards, Martin On Tue, 2018-10-23 at 17:25 +1300, Adrian Croucher wrote: > 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 > > -- ----------------------------------------------- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 ------------------------------------------------- Please consider that invitations and e-mails of our institute are only valid if they end with …@mpie.de. If you are not sure of the validity please contact [email protected] Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …@mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an [email protected] ------------------------------------------------- Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1 D-40237 Düsseldorf Handelsregister B 2533 Amtsgericht Düsseldorf Geschäftsführung Prof. Dr. Gerhard Dehm Prof. Dr. Jörg Neugebauer Prof. Dr. Dierk Raabe Dr. Kai de Weldige Ust.-Id.-Nr.: DE 11 93 58 514 Steuernummer: 105 5891 1000 Please consider that invitations and e-mails of our institute are only valid if they end with …@mpie.de. If you are not sure of the validity please contact [email protected] Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails aus unserem Haus nur mit der Endung …@mpie.de gültig sind. In Zweifelsfällen wenden Sie sich bitte an [email protected] -------------------------------------------------
