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

Smith, Barry F. bsmith at mcs.anl.gov
Sat Oct 20 11:22:04 CDT 2018



> 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.
> 
> 
> 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
> -------------------------------------------------



More information about the petsc-dev mailing list