Randall, I have resolved in the problem in branch barry/fortran-initialize-objects (now in next for testing) which defaults to initializing the PETSc objects in Fortran and removes the use of PetscObjects in Fortran common blocks to prevent compile errors. Soon will be in master
Barry > On Jan 18, 2018, at 5:08 PM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote: > > > Sorry this is actually in master already > > >> On Jan 18, 2018, at 5:00 PM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote: >> >> >> This is a known issue without a perfect solution. >> >> The problem is that by default PETSc fortran types, like type(tKSP) are not >> initialized but we want to check if they are a special null character, for >> example PETSC_NULL_KSP. So we could initialize them but then they cannot be >> used in common blocks (since default initialized Fortran90 types cannot be >> used in common blocks; some strange feature of Fortran 90) >> >> In next you can configure with the option -with-fortran-type-initialize=1 >> and the valgrind errors will go away, but then there cannot be Fortran >> datatypes into common blocks. >> >> Barry >> >> It may be we should make -with-fortran-type-initialize=1 the default but >> this will break some PETSc Fortran examples that use common blocks. We >> should rewrite those examples not to use common blocks but who volunteers? >> >> >> >> >> >> >>> On Jan 18, 2018, at 4:11 PM, Randall Mackie <rlmackie...@gmail.com> wrote: >>> >>> The very simple attached program throws lots of valgrind errors. >>> I am using pets 3.8.3, compiled with the following options: >>> >>> >>> ./configure \ >>> --with-debugging=1 \ >>> --with-fortran=1 \ >>> --download-mpich=../mpich-3.3a2.tar.gz \ >>> >>> >>> The makefile, run file, and valgrind output are also attached. >>> >>> >>> Randy M. >>> >>> >>> >>> >>> <cmd_test><makefile><test.F90><valgrind.txt> >> >
