[petsc-dev] Fortran interface problem in v.3.10.2

Sat Oct 20 12:51:08 CDT 2018


> On Oct 20, 2018, at 12:43 PM, Martin Diehl <m.diehl at mpie.de> wrote:
> 
> From: "Smith, Barry F." <bsmith at mcs.anl.gov> 
> To: Martin Diehl <m.diehl at mpie.de> 
> Cc: Adrian Croucher <a.croucher at auckland.ac.nz>, For users of the development version of PETSc <petsc-dev at 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.diehl at 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? 
> 
> 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/libifcoremt.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.croucher at 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.croucher at 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.croucher at 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 rco at 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 rco at 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 rco at 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 rco at 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 rco at 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 rco at mpie.de
> -------------------------------------------------