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

Mon Oct 22 08:55:07 CDT 2018

On Sat, 2018-10-20 at 17:51 +0000, Smith, Barry F. wrote:
> > 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?
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.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
> > -------------------------------------------------
> 
> 
-- 
-----------------------------------------------
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
-------------------------------------------------