Bug 33847 - Interface statement not detected: generate Error: Type/rank mismatch
Interface statement not detected: generate Error: Type/rank mismatch
Status: RESOLVED INVALID
Product: gcc
Classification: Unclassified
Component: fortran
4.3.0
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-21 06:53 UTC by Martien Hulsen
Modified: 2007-10-21 10:33 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martien Hulsen 2007-10-21 06:53:29 UTC
The following code gives:

t.f90:41.12:

  call sub ( shape_line_P1 )
           1
Error: Type/rank mismatch in argument 'sub1' at (1)

I tested ifort, lahey, g95 without any problem.


module int_m
  interface shape_line_P1
    module procedure shape_line_P1, shape_line_P1_2
  end interface
contains
  subroutine shape_line_P1 ( xr, phi, dphi )
    real, intent(in), dimension(:) :: xr
    real, intent(out), dimension(:,:) :: phi
    real, intent(out), dimension(:,:), optional :: dphi
    phi = 0
    dphi = 0
  end subroutine shape_line_P1
  subroutine shape_line_P1_2 ( xr, phi, dphi )
    real, intent(in), dimension(:,:) :: xr
    real, intent(out), dimension(:,:) :: phi
    real, intent(out), dimension(:,:,:), optional :: dphi
    phi = 0
    dphi = 0
  end subroutine shape_line_P1_2
end module int_m
module tt
  use int_m
contains
   subroutine sub ( sub1 )
    interface
      subroutine sub1 ( xr, phi, dphi )
        real, intent(in), dimension(:,:) :: xr
        real, intent(out), dimension(:,:) :: phi
        real, intent(out), dimension(:,:,:), optional :: dphi
      end subroutine sub1
    end interface
    real, dimension(2,1) :: xr
    real, dimension(2,2) :: phi
    real, dimension(2,2,1) :: dphi
    xr = 0
   call sub1 ( xr, phi, dphi )
   end subroutine sub
end module tt
program z
  use tt
  call sub ( shape_line_P1 )
end program z
Comment 1 Tobias Burnus 2007-10-21 10:07:21 UTC
(And the program is accepted using the patch from bug 33162 comment 2, however, I think the patch is the wrong to solution for this PR and bug 33162.)

NAG f95 also gives the following error:

Error: line 41: Actual proc SHAPE_LINE_P1 arg 1 is assumed-shape or POINTER array with different rank from dummy proc SUB1 arg
Error: line 41: Incompatible procedure argument for SUB1 (no. 1) of SUB

The program works if one changes
    call sub ( shape_line_P1 )    ! Generic  functions; specific: *_1, *_2
into
    call sub ( shape_line_P1_2 )  ! Specific function

Ad hoc, I expect that the program is valid, but I still have to check the standard.
Comment 2 Tobias Burnus 2007-10-21 10:33:28 UTC
I cannot read. You used:

  interface shape_line_P1
    module procedure shape_line_P1, shape_line_P1_2
  end interface

Thus "shape_line_P1" is both a specific subroutine and a generic subroutine, however, the standard mandates:

"If the specific name is also a generic name, only the specific procedure is associated with the dummy argument."

And as the specific subroutine "shape_line_P1" does not match the interface of sub's dummy argument "sub1", the program is invalid and the error printed by gfortran and NAG f95 is correct.

To fix the program, change:
    call sub ( shape_line_P1 )    ! wrong specific function
into
    call sub ( shape_line_P1_2 )  ! correct specific function

-----------------

Now to the thing I read:

  interface shape_line_P1
    module procedure shape_line_P1_1, shape_line_P1_2
  end interface !_________________^^

which means that "shape_line_P1" is only a generic function and not a specific function. However, this is also invalid and properly rejected by gfortran. The standard writes:

For "a dummy procedure[...], the associated actual argument shall be the specific name".

Here, gfortran writes:
"Error: GENERIC non-INTRINSIC procedure 'shape_line_p1' is not allowed as an actual argument"

----------------

Longer excerpt from the Fortran 2003 standard:

"12.4.1.3 Actual arguments associated with dummy procedure entities"
[...]
"If a dummy argument is a dummy procedure without the POINTER attribute, the associated actual argument shall be the specific name of an external, module, dummy, or intrinsic procedure, an associated procedure pointer, or a reference to a function that returns an associated procedure pointer. The only intrinsic procedures permitted are those listed in 13.6 and not marked with a bullet (*). If the specific name is also a generic name, only the specific procedure is associated with the dummy argument."

----------------------------

Closed as invalid on this basis of this analysis.

Nonetheless, thanks for reporting bugs in general - as user feedback is essential to iron out bugs and sometimes it is not obvious whether something is a bug or not.