[ET Trac] [Einstein Toolkit] #1567: Lorene: compilation error when using -warn all

[Einstein Toolkit]

#1567: Lorene: compilation error when using -warn all
--------------------------------------+-------------------------------------
 Reporter:  bmundim                   |       Owner:            
     Type:  defect                    |      Status:  new       
 Priority:  major                     |   Milestone:  ET_2014_05
Component:  EinsteinToolkit thorn     |     Version:  ET_2013_11
 Keywords:  Lorene ExternalLibraries  |  
--------------------------------------+-------------------------------------
 If I add the warning flag to fortran flags in my configuration option
 list, i.e.:

 F77_WARN_FLAGS = -warn all
 F90_WARN_FLAGS = -warn all

 Lorene's compilation abort with the following error messages:

 ...
 fcir2s.f(216): error #7983: The storage extent of the dummy argument
 exceeds that of the actual argument.   [NDEG1]
        CALL CIRX2S(NDEG1,NDIMR,NN64,ITCH,IDR,IND,C64,CC,CS,DENT)
 -------------------^
 fcir2s.f(240): error #7983: The storage extent of the dummy argument
 exceeds that of the actual argument.   [NDEG1]
        CALL CIRX2S(NDEG1,NDIMR,NN64,ITCH,IDR,IND,C64,CC,CS,DENT)
 -------------------^
 ...

 gr2p3s.f(719): error #8284: If the actual argument is scalar, the dummy
 argument shall be scalar unless the actual argument is of type character
 or is an element of an array that is not assumed shape, pointer, or
 polymorphic.   [SOM]
         CALL EXRM1S(NR,NDR,1,1,0,IPP,CC,VA1)
 -------------^
 gr2p3s.f(720): error #8284: If the actual argument is scalar, the dummy
 argument shall be scalar unless the actual argument is of type character
 or is an element of an array that is not assumed shape, pointer, or
 polymorphic.   [SOM]
         CALL EXRM1S(NR,NDR,1,1,1,IPP,CC,DE1)
 -------------^


 The first compilation error above indicates that NDEG1 is an array
 with dimension 2 in the calling subroutine FCIR2S while NDEG has
 dimension 3 in the called subroutine CIRX2S. A suggestion to
 work around this issue can be found at:

 http://software.intel.com/en-us/forums/topic/299025

 and it boils down to make them both of the same dimension.
 Would you suggest a different workaround? Maybe make the
 dummy array dimension a (*)?


 Regarding the second type of error above, I am not sure yet which
 argument is actually causing trouble. My local version of Lorene
 indicates different line number than the error line above but
 essentially the difference between the calls that the compiler
 complaints and the ones it doesn't is the following:

 grep -i -n  EXRM1S gr2p3s.f

 gr2p3s.f:694:   CALL EXRM1S(NR,NDR,LF1,1,0,IPP,CC,C64)
 gr2p3s.f:695:   CALL EXRM1S(NR,NDR,LF1,1,1,IPP,CC,UGRAV)
 gr2p3s.f:718:   CALL EXRM1S(NR,NDR,1,1,0,IPP,CC,VA1)
 gr2p3s.f:719:   CALL EXRM1S(NR,NDR,1,1,1,IPP,CC,DE1)

 On lines 694 and 695 there is no complaint from the compiler.
 While lines 718 and 719 do. So the dummy argument LF1 seems
 to prevent this compilation error in an earlier call.
 In any case, do you have any idea on how to fix this?

 Note that a workaround I found was to disable the compiler check
 for the subroutine interfaces by adding the following flag:

 F77_WARN_FLAGS = -warn all -warn nointerfaces
 F90_WARN_FLAGS = -warn all -warn nointerfaces

 However I would rather have this issue addressed than let it go
 silently. Besides it might affect other fortran codes in ET which
 I haven't had the opportunity to investigate yet. I have posted
 a message on Lorene mailing list about this issue. If I don't hear
 from them, maybe we should come up with a patch on our own. Could
 someone more familiar with Lorene inner workings come up with
 a suggestion for this patch? I could work on it and test it.

 Thanks,
 Bruno.

 PS: I found this article useful:
 http://software.intel.com/en-us/blogs/2009/03/31/doctor-fortran-in-ive-
 come-here-for-an-argument

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1567>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit