Tue, 16 Mar 2021, Jacob Faibussowitsch wrote:

> Ok something I have gotten to work, but only doing things by hand in 
> petscvecmod.F90:
> 
> diff --git a/src/vec/f90-mod/petscvecmod.F90 b/src/vec/f90-mod/petscvecmod.F90
> index 0c447156b9..ef3e2e2e55 100644
> --- a/src/vec/f90-mod/petscvecmod.F90
> +++ b/src/vec/f90-mod/petscvecmod.F90
>  module petscisdef
>  use petscisdefdummy
>  interface operator(.ne.)
>  function isnotequal(A,B)
> -  use petscisdefdummy
> + import tIS
>    logical isnotequal                                                         
>             
>    type(tIS), intent(in) :: A,B

generatefortranstubs.py has some hakey parsing code. I guess it can be updated 
to do this.

i.e - look for 'type(tIS)' and add 'import tIS'

>  end function isnotequal
> 
> This works for everything wrapped in a module which contains an interface 
> block. For dangling functions the following works:

Hm - maybe these are only on the custom side [and not ftn-auto side]

Satish
> 
>  function isnotequal(A,B)
> -  use petscisdefdummy
> + use petscisdef, only: tIs


>    logical isnotequal
>    type(tIS), intent(in) :: A,B
>    isnotequal = (A%v .ne. B%v)
>  end function isnotequal
> 
> Do our fortran stub generators have any notion of types? Specifically types 
> that originate from petsc?
> 
> Best regards,
> 
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391
> 
> > On Mar 16, 2021, at 11:11, Satish Balay <[email protected]> wrote:
> > 
> > On Tue, 16 Mar 2021, Jacob Faibussowitsch wrote:
> > 
> >>> My [partial] change is in branch balay/reorg-f90-for-xlf
> >> 
> >> Satish is this branch pushed? I’d like to send it to the ibm folks to see 
> >> if it works for them as well.
> > 
> > Sorry - pushed now. From what I remember - it didn't work.
> > 
> > Satish
> > 
> > 
> >> They also added this extra follow up:
> >> 
> >> The change we did in the source files is to replace all the "use pet*" 
> >> statements in all the Interface blocks with IMPORT statement.
> >> 
> >> The nature of this workaround is to reduce the number of symbols that the 
> >> compiler have to create, which exceeded the limitation and caused ICE.
> >> 
> >> Every USE statement in an interface block opens up the module symbol file 
> >> and reads all the symbols from it and creates an entity for each symbol in 
> >> compiler. This is unnecessary when the module already has the same USE 
> >> statement in the module scope. Instead, users can use IMPORT statement to 
> >> make the module symbols accessible inside interface face blocks.
> >> 
> >> With the change, the compiler would only read the module symbol file once 
> >> and create one set of symbols where the old code reads the module symbol 
> >> files as many times as the number of the USE statements in Interface 
> >> blocks and create that many sets of duplicate symbols. Replacing those USE 
> >> statements with IMPORT statements also shortens the compile time 
> >> significantly.
> >> 
> >> Best regards,
> >> 
> >> Jacob Faibussowitsch
> >> (Jacob Fai - booss - oh - vitch)
> >> Cell: (312) 694-3391
> >> 
> >>> On Mar 3, 2021, at 13:43, Satish Balay via petsc-dev 
> >>> <[email protected]> wrote:
> >>> 
> >>> The only change I can get working (i.e avoid compile errors) is to split 
> >>> petscvecmod.F90 into 2 source files - but I don't know if this will help 
> >>> with xlf..
> >>> 
> >>> My [partial] change is in branch balay/reorg-f90-for-xlf
> >>> 
> >>> Satish
> >>> 
> >>> On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote:
> >>> 
> >>>> On Wed, 3 Mar 2021, Satish Balay via petsc-dev wrote:
> >>>> 
> >>>>> Sure - once any change works locally [for gcc and xlf]
> >>>>> 
> >>>>> When I try - I get a bunch of errors.. [yet to digest them.]
> >>>> 
> >>>>>>>>> Can you please give the following source code workaround a try?
> >>>>>>>>> Since there is already "use petscvecdefdummy" at the module scope, 
> >>>>>>>>> one workaround might be to remove the unnecessary "use 
> >>>>>>>>> petscvecdefdummy" in vecnotequal and vecequals 
> >>>>>>>>> and all similar procedures.
> >>>>>>>>> 
> >>>>>>>>> For example, the test case has:
> >>>>>>>>>      module petscvecdef
> >>>>>>>>>      use petscvecdefdummy
> >>>>>>>>> ...
> >>>>>>>>>      function vecnotequal(A,B)
> >>>>>>>>>        use petscvecdefdummy
> >>>>>>>>>        logical vecnotequal
> >>>>>>>>>        type(tVec), intent(in) :: A,B
> >>>>>>>>>        vecnotequal = (A%v .ne. B%v)
> >>>>>>>>>      end function
> >>>> 
> >>>> 
> >>>> Ok - try this suggestion:
> >>>> 
> >>>> diff --git a/src/vec/f90-mod/petscvecmod.F90 
> >>>> b/src/vec/f90-mod/petscvecmod.F90
> >>>> index 0c447156b9..81968c7ca1 100644
> >>>> --- a/src/vec/f90-mod/petscvecmod.F90
> >>>> +++ b/src/vec/f90-mod/petscvecmod.F90
> >>>> @@ -77,7 +77,6 @@
> >>>>        use petscvecdefdummy
> >>>>        interface operator(.ne.)
> >>>>          function vecnotequal(A,B)
> >>>> -            use petscvecdefdummy
> >>>>            logical vecnotequal
> >>>>            type(tVec), intent(in) :: A,B
> >>>>          end function
> >>>> 
> >>>> 
> >>>>>>>>> 
> >>>>         FC arch-linux-c-debug/obj/vec/f90-mod/petscvecmod.o
> >>>> /home/balay/petsc/src/vec/f90-mod/petscvecmod.F90:81:22:
> >>>> 
> >>>>  81 |             type(tVec), intent(in) :: A,B
> >>>>     |                      1
> >>>> Error: Derived type ‘tvec’ at (1) is being used before it is defined
> >>>> /home/balay/petsc/include/../src/vec/f90-mod/ftn-auto-interfaces/petscis.h90:2:10:
> >>>> 
> >>>>   2 |       use petscvecdef
> >>>>     |          1
> >>>> Fatal Error: Cannot open module file ‘petscvecdef.mod’ for reading at 
> >>>> (1): No such file or directory
> >>>> <<<<<<
> >>>> 
> >>>> Satish
> >> 
> >> 
> 
> 

Reply via email to