On Sat, 2018-10-20 at 17:51 +0000, Smith, Barry F. wrote: > > On Oct 20, 2018, at 12:43 PM, Martin Diehl <m.di...@mpie.de> wrote: > > > > From: "Smith, Barry F." <bsm...@mcs.anl.gov> > > To: Martin Diehl <m.di...@mpie.de> > > Cc: Adrian Croucher <a.crouc...@auckland.ac.nz>, For users of the > > development version of PETSc <petsc-dev@mcs.anl.gov> > > Sent: 10/20/2018 6:22 PM > > Subject: Re: [petsc-dev] Fortran interface problem in v.3.10.2 > > > > > > > > > On Oct 20, 2018, at 6:13 AM, Martin Diehl <m.di...@mpie.de> > > > wrote: > > > > > > Barry, Adrian, > > > > > > I looked into this and found the following on type(*) from IBM > > > > > > https://www.ibm.com/support/knowledgecenter/SSAT4T_15.1.4/com.ibm.xlf1514.lelinux.doc/language_ref/assumedtypeobj.html > > > > > > > > > To summarize, type(*) is exactly meant for C interfaces with > > > void* > > > dummy arguments (sorry for the Fortran speak, I don't know if > > > dummy > > > argument is a term common in C programming). > > > > > > The last statement is > > > "An assumed-type dummy argument cannot correspond to an actual > > > argument > > > of a derived type that has type parameters, type-bound > > > procedures, or > > > final subroutines." > > > which seems to be the reason why the code does not compile. > > > > I am now concerned that our use of type(*) in PETSc Fortran > > interfaces is just wrong and I see no good solution except to not > > have interface definitions for any Fortran stub routines that have > > void *arguments. > > To my understanding, it is fine. type(*) was meant for interfacing > > *void and that's what you use it for. However, it imposes some > > restrictions on the actual argument. For that reason, Intel Fortran > > does not compile the example code, with or without explicit > > interface. GNU fortran compiles the code without interface, > > presumably because it cannot detect that the code is not standard > > conforming. > > 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 > > > > I propose to further clarify the situation I'll present the problem > > at the Intel Developer Zone forum. > > > > > > > > > > > Then, I tried the following things: > > > > > > 1) Compiling your code with the current PETSc master and gfortran > > > 8.2 > > > to check whether this issue has been fixed by the GCC > > > developers. > > > > > > It still gives the same error > > > > > > > > > 2) Compiling your code with the Intel Fortran compiler (18.0.1) > > > an the > > > current PETSc master. > > > > > > It gives a very cryptic error > > > /usr/bin/x86_64-linux-gnu-ld: test_snes.o: undefined reference > > > to > > > symbol 'for_set_reentrancy' > > > /opt/intel/compilers_and_libraries_2018/linux/lib/intel64/libifco > > > remt.s > > > o.5: error adding symbols: DSO missing from command line > > > See also https://software.intel.com/en-us/node/679295 > > > > > > > > > 3) Compiling your code with the Intel Fortran compiler and either > > > PETSc > > > 3.10.0 or the PETSc master without the Fortran interface for > > > SNESsetConvergenceTest > > > > > > It still gives the same error as for 2) > > > > > > > > > Do you have access to any other compilers to check whether they > > > can > > > compile your application/test_example? > > > > > > best regards > > > Martin > > > > > > > > > > > > > > > On Fri, 2018-10-19 at 19:52 +0000, Smith, Barry F. wrote: > > > > > > > > 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 < > > > > > > > > a.crouc...@auckland.ac.nz> 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 < > > > > > > > > a.crouc...@auckland.ac.nz> 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: a.crouc...@auckland.ac.nz > > > > > tel: +64 (0)9 923 4611 > > > > > > > > > > <test_snes.F90> > > > > > > -- > > > ----------------------------------------------- > > > 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 r...@mpie.de > > > > > > 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 r...@mpie.de > > > > > > > > > > > > ------------------------------------------------- > > > 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 r...@mpie.de > > > > > > 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 r...@mpie.de > > > ------------------------------------------------- > > > > > > > > ------------------------------------------------- > > 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 r...@mpie.de > > > > 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 r...@mpie.de > > ------------------------------------------------- > > -- ----------------------------------------------- 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 r...@mpie.de 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 r...@mpie.de ------------------------------------------------- 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 r...@mpie.de 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 r...@mpie.de -------------------------------------------------