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

Sat Oct 20 06:13:10 CDT 2018

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.

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