I have this list in my branch [this list is created based on compiler errors - from the auto-generated fortran stubs - so perhaps incomplete].
Can you try my branch and see if that change is sufficient for xlf? Satish --------- +ptypes = [ + 'PetscRandom', + 'IS', + 'Vec', + 'PetscViewer', + 'PetscOptions', + 'PetscSubcomm', + 'ISColoring', + 'PetscSection', + 'VecTagger', + 'MatNullSpace', + 'Mat', + 'MatFDColoring', + 'VecScatter', + 'DMLabel', + 'DM', + 'PetscSectionSym', + 'PetscSF', + 'DMPlexCellRefiner', + 'KSP', + 'PC', + 'KSPGuess', + 'PetscConvEst', + 'SNES', + 'TSTrajectory', + 'TS', + 'TSAdapt', +] On Tue, 16 Mar 2021, Jacob Faibussowitsch wrote: > So I have hit a bit of a wall. I am able to pull out all of the types for a > subroutine declaration but I cannot determine which types are classes since > those are the ones that need to be imported. For example: > > subroutine PetscMatlabEngineDestroy(a,z) > > PetscMatlabEngine a ! PetscMatlabEngine > PetscErrorCode z > end subroutine PetscMatlabEngineDestroy > > Is compiles completely fine but > > subroutine PetscRandomDestroy(a,z) > > PetscRandom a ! PetscRandom > PetscErrorCode z > end subroutine PetscRandomDestroy > > Requires an “import tPetscRandom”. Previously both of these had “import > petscsys” stuck in them. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > > > On Mar 16, 2021, at 16:13, Satish Balay via petsc-dev > > <[email protected]> wrote: > > > > And with this change (alone) - the time to compile the f90 modules went (on > > pj01 testbox) from: > > > > 0m48.676s > > to > > 0m15.053s > > > > Satish > > > > On Tue, 16 Mar 2021, Satish Balay via petsc-dev wrote: > > > >> Ah - the issue is 'import IS' vs 'import tIS' > >> > >> Pushed a fix now. [and reverted my earlier source split change]. My build > >> goes through fine now. > >> > >> Satish > >> > >> On Tue, 16 Mar 2021, Barry Smith wrote: > >> > >>> > >>> Satish, > >>> > >>> The import tIS might only work because the IS is already defined in > >>> the same file so the compiler can pull in just part of the use > >>> petscisdefdummy ? If the original module that contains the PetscRandom is > >>> in a different file then I don't see how the compiler can find and import > >>> PetscRandom. Is there a version of import where you also list the module > >>> (file) that the beast is from so the compiler can get it from that module? > >>> > >>> Barry > >>> > >>> Do both the manually generated petsc*mod.F90 and the automatically > >>> generated files need to be switched to not use use everywhere? Or is it > >>> enough just to fix the manual ones for now and not mess with sowing? > >>> > >>> > >>> > >>>> On Mar 16, 2021, at 2:34 PM, Satish Balay via petsc-dev > >>>> <[email protected]> wrote: > >>>> > >>>> On Tue, 16 Mar 2021, Satish Balay via petsc-dev wrote: > >>>> > >>>>> > >>>>> > >>>>> 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' > >>>> > >>>> I pushed changes to generatefortranstubs.py for this (to > >>>> balay/reorg-f90-for-xlf branch). But there are errors. (I don't > >>>> completely understand this issue yet) > >>>> > >>>>>>> > >>>> FC arch-linux-c-debug/obj/sys/f90-mod/petscsysmod.o > >>>> /home/balay/petsc/include/../src/sys/f90-mod/ftn-auto-interfaces/petscsys.h90:6:19: > >>>> > >>>> 6 | import PetscRandom > >>>> | 1 > >>>> Error: Cannot IMPORT ‘type’ from host scoping unit at (1) - does not > >>>> exist. > >>>> /home/balay/petsc/include/../src/sys/f90-mod/ftn-auto-interfaces/petscsys.h90:7:26: > >>>> > >>>> 7 | PetscRandom a ! PetscRandom > >>>> | 1 > >>>> Error: Derived type ‘tpetscrandom’ at (1) is being used before it is > >>>> defined > >>>> <<<< > >>>> > >>>> > >>>> Satish > >>>> > >>>>> > >>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>>> > >>> > >
