[Bug fortran/45210] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||WORKSFORME --- Comment #8 from kargl at gcc dot gnu.org 2010-11-03 17:07:47 UTC --- This appears to be fixed on 4.4, 4.5, and trunk (unless I'm doing something wrong). I'm closing this PR with WORKSFORME. troutmask:sgk[202] gfc4x -c p1.f90 troutmask:sgk[203] gfc4x -c p2.f90 troutmask:sgk[204] rm p1.o p2.o *.mod troutmask:sgk[205] gfc45 -c p1.f90 troutmask:sgk[206] gfc45 -c p2.f90 troutmask:sgk[207] rm p1.o p2.o *.mod troutmask:sgk[208] gfc44 -c p1.f90 troutmask:sgk[209] gfc44 -c p2.f90 troutmask:sgk[210] rm p1.o p2.o *.mod troutmask:sgk[211] gfc43 -c p1.f90 troutmask:sgk[212] gfc43 -c p2.f90 p2.f90:66.25: CALL ijk_to_i_j_k(i_j_k,i_j_k_fid,grid_size) 1 Error: Rank mismatch in argument 'j' at (1) (0 and 1)
[Bug fortran/45210] compilation error
--- Comment #7 from dominiq at lps dot ens dot fr 2010-08-06 21:09 --- Thanks to Thomas König, the mystery is sorted out: both p1.f90 and p2.f90 contain a subroutine ijk_to_i_j_k. In p1 the subroutine has the right dummy arguments for the call, while the one in p2 has wrong ones. Due to USE module_ijk_to_i_j_k ,ONLY:ijk_to_i_j_k in SUBROUTINE i_j_k_to_ijk(i_j_k,size,i,j,k), the call to ijk_to_i_j_k should use the one in p1 (as with 4.6) and not the one in p2 (as with 4.4 or 4.5). So if the above is right, the bug has been fixed in 4.6, but not backported to 4.5. Can you check where and with actual arguments the subroutine i_j_k_to_ijk is called in the full code? If all the calls are to the subroutine in p1, you can probably remove the one in p2. If both subroutines are called, some with the argument list corresponding to p1 and some with the argument list corresponding to p2, you can try to rename one of the subroutines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #6 from dominiq at lps dot ens dot fr 2010-08-06 18:42 --- > Your right, I assumed blindly that this code makes at least some sense (I > modified it to remove the dependencies, but the main issue remains the same). > However, it compiles with Pathscale 3.1 and SunStudio 12.1 (probably also > others, as a Windows binary of this beautiful artwork is available). Is it > normal that a routine can prevent compilation of a preceding one? Well, I cannot see how the code you POSTED (you may have introduced a problem when reducing the code, it is quite common) could be valid according the Fortran standard. However I think the constraints that the actual and dummy must match are put under a "shall", i.e. the burden is on the user and the compiler may or may not detect the problem (put the call and the subroutine in two different files instead of in a CONTAINS unit and the compiler has no way to check that the actual and dummy argument match: a very common mistake when using libraries). CCed Steven G. Kargl for additional opinion. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #5 from sliwa at blue dot cft dot edu dot pl 2010-08-06 18:07 --- Your right, I assumed blindly that this code makes at least some sense (I modified it to remove the dependencies, but the main issue remains the same). However, it compiles with Pathscale 3.1 and SunStudio 12.1 (probably also others, as a Windows binary of this beautiful artwork is available). Is it normal that a routine can prevent compilation of a preceding one? PS. A colleague of mine is going to use this program compiled with one of the above compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #4 from dominiq at lps dot ens dot fr 2010-08-06 17:22 --- Confirmed on 4.4.4 and 4.5.0, but the test compiles with trunk (with/without -fno-whole-file). Now I see: ... CALL ijk_to_i_j_k(i_j_k,i_j_k_fid,grid_size) ... SUBROUTINE ijk_to_i_j_k(i,j,k,size,i_j_k) The call has 3 arguments and the subroutine 5. In addition i_j_k_fid is a rank one array and j a scalar, so the error makes sense for me. What I don't understand is why this is not detected with 4.6. Should not the summary be "[4.6 Regression] missing error"? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #3 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:49 --- To reproduce: 1. gfortran -c p1.f90 (no message) 2. gfortran -c p2.f90 p2.f90:66.25: CALL ijk_to_i_j_k(i_j_k,i_j_k_fid,grid_size) 1 Error: Rank mismatch in argument 'j' at (1) (0 and 1) 3. Now copy the first routine from p2.f90 to p2a.f90 gfortran -c p2a.f90 (no message) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #2 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:45 --- Created an attachment (id=21425) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21425&action=view) second part of the test case This file contains to routines. The error is reported in the first one, but after removing the second one no error is reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
[Bug fortran/45210] compilation error
--- Comment #1 from sliwa at blue dot cft dot edu dot pl 2010-08-06 16:43 --- Created an attachment (id=21424) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21424&action=view) p1.f90 first part of the test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45210
