* [Bug fortran/45210] compilation error
2010-08-06 16:41 [Bug fortran/45210] New: compilation error sliwa at blue dot cft dot edu dot pl
@ 2010-08-06 16:43 ` sliwa at blue dot cft dot edu dot pl
2010-08-06 16:46 ` sliwa at blue dot cft dot edu dot pl
` (5 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: sliwa at blue dot cft dot edu dot pl @ 2010-08-06 16:43 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug fortran/45210] compilation error
2010-08-06 16:41 [Bug fortran/45210] New: compilation error sliwa at blue dot cft dot edu dot pl
2010-08-06 16:43 ` [Bug fortran/45210] " sliwa at blue dot cft dot edu dot pl
@ 2010-08-06 16:46 ` sliwa at blue dot cft dot edu dot pl
2010-08-06 16:49 ` sliwa at blue dot cft dot edu dot pl
` (4 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: sliwa at blue dot cft dot edu dot pl @ 2010-08-06 16:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug fortran/45210] compilation error
2010-08-06 16:41 [Bug fortran/45210] New: compilation error sliwa at blue dot cft dot edu dot pl
2010-08-06 16:43 ` [Bug fortran/45210] " sliwa at blue dot cft dot edu dot pl
2010-08-06 16:46 ` sliwa at blue dot cft dot edu dot pl
@ 2010-08-06 16:49 ` sliwa at blue dot cft dot edu dot pl
2010-08-06 17:22 ` dominiq at lps dot ens dot fr
` (3 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: sliwa at blue dot cft dot edu dot pl @ 2010-08-06 16:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug fortran/45210] compilation error
2010-08-06 16:41 [Bug fortran/45210] New: compilation error sliwa at blue dot cft dot edu dot pl
` (2 preceding siblings ...)
2010-08-06 16:49 ` sliwa at blue dot cft dot edu dot pl
@ 2010-08-06 17:22 ` dominiq at lps dot ens dot fr
2010-08-06 18:07 ` sliwa at blue dot cft dot edu dot pl
` (2 subsequent siblings)
6 siblings, 0 replies; 9+ messages in thread
From: dominiq at lps dot ens dot fr @ 2010-08-06 17:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug fortran/45210] compilation error
2010-08-06 16:41 [Bug fortran/45210] New: compilation error sliwa at blue dot cft dot edu dot pl
` (3 preceding siblings ...)
2010-08-06 17:22 ` dominiq at lps dot ens dot fr
@ 2010-08-06 18:07 ` sliwa at blue dot cft dot edu dot pl
2010-08-06 18:42 ` dominiq at lps dot ens dot fr
2010-08-06 21:09 ` dominiq at lps dot ens dot fr
6 siblings, 0 replies; 9+ messages in thread
From: sliwa at blue dot cft dot edu dot pl @ 2010-08-06 18:07 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug fortran/45210] compilation error
2010-08-06 16:41 [Bug fortran/45210] New: compilation error sliwa at blue dot cft dot edu dot pl
` (4 preceding siblings ...)
2010-08-06 18:07 ` sliwa at blue dot cft dot edu dot pl
@ 2010-08-06 18:42 ` dominiq at lps dot ens dot fr
2010-08-06 21:09 ` dominiq at lps dot ens dot fr
6 siblings, 0 replies; 9+ messages in thread
From: dominiq at lps dot ens dot fr @ 2010-08-06 18:42 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug fortran/45210] compilation error
2010-08-06 16:41 [Bug fortran/45210] New: compilation error sliwa at blue dot cft dot edu dot pl
` (5 preceding siblings ...)
2010-08-06 18:42 ` dominiq at lps dot ens dot fr
@ 2010-08-06 21:09 ` dominiq at lps dot ens dot fr
6 siblings, 0 replies; 9+ messages in thread
From: dominiq at lps dot ens dot fr @ 2010-08-06 21:09 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread