[petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines
Matthew Knepley
knepley at gmail.com
Tue Mar 16 14:05:27 CDT 2021
On Tue, Mar 16, 2021 at 2:42 PM Jacob Faibussowitsch <jacob.fai at gmail.com>
wrote:
> To me the best solution is to first split the files when possible (it is
> often not or just too painful) and then adding imports if needed.
>
>
> I’m not sure I agree. Bear in mind my familiarity with fortran is very
> limited, but to me the “use” statement is similar to #include <header> in C
> or using namespace xxx in cpp.
>
> Our fortran interface is not optimal code atm, it’s as if we put a
> "#include <petscvec.h>” before every Vec function in the C source
> (assuming include guards are not used). Sure you can fix this by splitting
> the vec src files in two, but at the end of the day that’s a bandaid
> solution. I think I can get the import stuff to work reasonably well (a lot
> of the infrastructure to capture types is already present in the current
> generatefortranstubs).
>
If you can get this to work, we should definitely do it. Was there a
question about getting it to work?
Thanks,
Matt
> Best regards,
>
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391
>
> On Mar 16, 2021, at 12:56, Barry Smith <bsmith at petsc.dev> wrote:
>
>
> Jacob,
>
> I split the mat definitions in the MR
> https://gitlab.com/petsc/petsc/-/merge_requests/3696 and this reduced
> memory requirements enough to get builds through on some VM that failed
> previously ran out of memory (with gfortran).
>
> The petsc*mod.F90 files are all handwritten so it is ok to manually
> change them with imports if that helps the IBM compiler. To me the best
> solution is to first split the files when possible (it is often not or just
> too painful) and then adding imports if needed.
>
> Note also the MR
> https://gitlab.com/petsc/petsc/-/merge_requests/3715/diffs which may help
> a great deal with the IBM compiler or not.
>
> Thanks
>
> Barry
>
>
>
> On Mar 16, 2021, at 11:47 AM, Jacob Faibussowitsch <jacob.fai at gmail.com>
> 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
> end function isnotequal
>
> This works for everything wrapped in a module which contains an interface
> block. For dangling functions the following works:
>
> 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 <balay at mcs.anl.gov> 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 <
> petsc-dev at mcs.anl.gov> 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
>
>
>
>
>
>
>
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20210316/399c43db/attachment-0001.html>
More information about the petsc-dev
mailing list