Sorry this is actually in master already
> On Jan 18, 2018, at 5:00 PM, Smith, Barry F. <[email protected]> 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 <[email protected]> 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> >
