#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