Bug 517578

Summary:

gfortran 4.1: Subroutine assumed-shape array dummy args require an explicit interface spec for the caller

Product:

Red Hat Enterprise Linux 5

Reporter:

Jeff Bastian <jbastian>

Component:

gcc

Assignee:

Jakub Jelinek <jakub>

Status:

CLOSED WONTFIX

QA Contact:

BaseOS QE <qe-baseos-auto>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

5.4

CC:

tao

Target Milestone:

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2009-10-28 10:06:12 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
demo program	none
demo program with required interface	none

Description Jeff Bastian 2009-08-14 19:03:21 UTC

Created attachment 357499 [details]
demo program

Description of problem:
gfortran41 (and gfortran44) accepts buggy code with no warnings or errors:
subroutine assumed-shape array dummy args require an explicit interface
spec for the caller.

From Ben Woodard:
    When you run code without the interface specification you can get 
    unexpected results. Depending on exactly what you do in the called
    routine, you can index into the array in a wrong way and get very
    unexpected results.

    The argument that an explicit interface is required for assumed
    shape arrays checks out in many sources including:
1. http://h21007.www2.hp.com/portal/download/files/unprot/fortran/docs/lrm/lrm0089.htm
2. http://www.mun.ca/hpc/hpf_pse/manual/hpf0033.htm
   See: 6.4.3 Explicit Interfaces
3. http://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/41911/reply/12572/

Version-Release number of selected component (if applicable):
gcc-gfortran-4.1.2-46.el5

How reproducible:
every time

Steps to Reproduce:
1. gfortran -g -Wall -o array_display array_display.f90

Actual results:
no error or warnings

Expected results:
There should be an error, or at the very least a warning, saying that a
subroutine that takes an assumed shape array must have an interface
specification in the calling routine.

Additional info:
Other compilers do give an error, for example:

$ pathf90 -g -O0 -o array_display_64_pathf90_3.1-g-O0 array_display.f90

subroutine subr1(y,p)
          ^         
pathf95-1277 pathf90: ERROR SUBR1, File = array_display.f90, Line = 12, Column
= 12
 Procedure "SUBR1" is referenced at line 9 (array_display.f90).  It must have
an explicit interface specified.

subroutine subr2(r,t,s,u,v,w,ar1,ar2,j,y,p)
          ^                                
pathf95-1277 pathf90: ERROR SUBR2, File = array_display.f90, Line = 29, Column
= 12
 Procedure "SUBR2" is referenced at line 26 (array_display.f90).  It must have
an explicit interface specified.

pathf95: PathScale(TM) Fortran Version 3.1 (f14) Thu Aug 13, 2009  15:08:15
pathf95: 45 source lines
pathf95: 2 Error(s), 0 Warning(s), 0 Other message(s), 0 ANSI(s)
pathf95: "explain pathf95-message number" gives more information about each
message

$ /usr/local/tools/pathscale/bin/explain pathf95-1277
Error : Procedure "%s" is %s at line %s.  It must have an explicit interface
specified.

12.3.1.1 The Fortran standard requires an explicit interface in the following
        situations:

  A procedure other than a statement function shall have an explicit interface
  if the procedure is elemental or the procedure has
      (a) An optional dummy argument
      (b) A dummy argument that is an assumed-shape array, a pointer or a
          target
      (c) An array-valued result (functions only.)
      (d) A result that is a pointer (functions only)
      (e) A result whose character length parameter value is not assumed and
          not constant

  During global semantics the compiler has detected a call to an external
  procedure and has found an explicit interface for that procedure in
  another program unit during compilation.  The explicit interface for that
  procedure describes the procedure as having one or more of the above
  characteristics.  These characteristics require that an explicit interface
  be specified for this program unit in all program units that reference this
  procedure.

Comment 1 Jeff Bastian 2009-08-14 19:08:18 UTC

Created attachment 357501 [details]
demo program with required interface

The correct form of the demo program.

--- array_display.f90   2009-08-14 13:31:34.000000000 -0500
+++ array_display_repaired.f90  2009-08-14 13:31:34.000000000 -0500
@@ -3,6 +3,13 @@
   integer, parameter:: dp=kind(0.d0)
   real(dp), pointer       :: p(:)
   real(dp)                :: x(1000)
+  interface
+    subroutine subr1(y,p)
+      integer, parameter:: dp=kind(0.d0)
+      real(dp), intent(in)    :: y(:)
+      real(dp), intent(in)    :: p(:)
+    end subroutine subr1
+  end interface
   allocate(p(1000))
   p(:) = 0._dp
   x(:) = 0._dp
@@ -21,6 +28,22 @@
   real(dp), allocatable   :: ar1(:)
   real(dp), allocatable   :: ar2(:,:)
   integer                 :: j
+  interface
+    subroutine subr2(r,t,s,u,v,w,ar1,ar2,j,y,p)
+      integer, parameter:: dp=kind(0.d0)
+      real(dp), intent(in)    :: r
+      real(dp), intent(in)    :: t(3)
+      real(dp), intent(in)    :: s
+      real(dp), intent(out)   :: u(3)
+      real(dp), intent(in)    :: v
+      real(dp), intent(in)    :: w
+      real(dp), intent(inout) :: ar1(:)
+      real(dp), intent(inout) :: ar2(:,:)
+      integer,  intent(inout) :: j
+      real(dp), intent(in)    :: y(:)
+      real(dp), intent(in)    :: p(:)
+    end subroutine subr2
+  end interface
   i = 4*size(p)
   allocate(ar1(i),ar2(3,i))
   call subr2(r,t,s,u,v,w,ar1,ar2,j,y,p)

Comment 2 Jakub Jelinek 2009-10-28 10:02:39 UTC

This isn't very different from calling a function which expects say real argument with integer one, etc., and when not using interfaces or modules you get no diagnostics for that either.  Even if a diagnostics is added (which would be very involved and risky patch for 4.4 at this point), it wouldn't catch the probably far more usual cases where the subroutine/function definition is in a different source from the caller.
Just use INTERFACE and/or MODULEs if you want function/subroutine type checking IMHO.

Comment 3 RHEL Program Management 2009-10-28 10:06:12 UTC

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.