[petsc-dev] Case TS005062693 - XLF: ICE in xlfentry compiling a module with 358 subroutines
Jacob Faibussowitsch
jacob.fai at gmail.com
Tue Mar 16 13:42:08 CDT 2021
> 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).
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 <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 <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 <mailto: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 <mailto: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 <mailto: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
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20210316/35c88180/attachment.html>
More information about the petsc-dev
mailing list