[Bug fortran/35831] New: Type-mismatch check missing for dummy procedure argument

[Bug fortran/35831] New: Type-mismatch check missing for dummy procedure argument

[burnus at gcc dot gnu dot org]

In the following program, the interface of the dummy procedure is explicit.

Fortran 2003's "12.4.1.3 Actual arguments associated with dummy procedure
entities" has about this:

"If the interface of the dummy argument is explicit, the characteristics listed
in 12.2 shall be the same for the associated actual argument and the
corresponding dummy argument, except that a pure actual argument may be
associated with a dummy argument that is not pure and an elemental intrinsic
actual procedure may be associated with a dummy procedure (which is prohibited
from being elemental)."

"If an external procedure name or a dummy procedure name is used as an actual
argument, its interface shall be explicit or it shall be explicitly declared to
have the EXTERNAL attribute."


gfortran does not seem to check whether the array arguments of dummy procedures
match. One reason could be that passing a "a(2)" array ("call foo(a)") to an
array "a(:)" is valid, but this does not apply here.

For some reason, gfortran checks this for
  PROCEDURE(<interface>) :: dummy
but not for
  INTERFACE; subroutine dummy() ...
in principle I had expected that both is handled identically. Remove the "!!"
to test the PROCEDURE version.

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/330df81363912681

Please also check the version given there (incl. the PROCEDURE version) when
fixing this PR.

program test
  implicit none
  interface
    subroutine one(a)
      integer a(:)
    end subroutine one
    subroutine two(a)
      integer a(2)
    end subroutine two
  end interface
  ! PROCEDURE dummy, gives error:
  !! call foo(two)    ! OK: "Type/rank mismatch in argument 'f'"
  ! Interface dummy, is accepted:
  call bar(two)  ! Invalid, not diagnosed
contains
! Valid, but gives an ICE in trans-*.c, see PR 35830
!!  subroutine foo(f)
!!    procedure(one) :: f
!!  end subroutine foo

  subroutine bar(f)
    interface
      subroutine f(a)
        integer a(:)
      end subroutine f
    end interface
  end subroutine bar
end program test


-- 
           Summary: Type-mismatch check missing for dummy procedure argument
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: accepts-invalid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[jaydub66 at gmail dot com]

------- Comment #1 from jaydub66 at gmail dot com  2008-04-08 20:58 -------
Tobias,

I can confirm the behaviour you described for this test case, provided of
course that "one" and "two" are implemented somewhere externally. Otherwise one
gets

undefined reference to `two_'

because there is only an interface for "two" but no actual implementation.


Now, if I apply the fix for PR35830, i.e. adding the following line in
"copy_formal_args":

formal_arg->sym->as = gfc_copy_array_spec (curr_arg->sym->as);

Then also the error message for "call foo(two)" goes away! So this "Type/rank
mismatch in argument 'f'" you saw before was apparently due to that
array-handling bug in "copy_formal_args"!


-- 

jaydub66 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jaydub66 at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[jaydub66 at gmail dot com]

------- Comment #2 from jaydub66 at gmail dot com  2008-04-09 18:23 -------
Here is a modified version of the original test case, which is also accepted by
gfortran, while it is rejected by ifort:


module m

contains

    subroutine one(a)
      integer a(1:2)
    end subroutine one

    subroutine two(a)
      integer a(2:3)
    end subroutine two

end module

program test
  use m
  implicit none

  ! PROCEDURE dummy
  !call foo(two)

  ! Interface dummy
  call bar(two)

contains

!   subroutine foo(f)
!     procedure(one) :: f
!   end subroutine foo

  subroutine bar(f)
    interface
      subroutine f(a)
        integer a(1:2)
      end subroutine f
    end interface
  end subroutine bar

end program test


In this test case both arrays are explicit-sized, and even have the same size,
but their upper and lower bounds are shifted. gfortran currently does not even
check if both arrays have the same size, only their ranks are compared.
ifort gives the following error message:

fortcom: Error: test35831.f90, line 23: The characteristics of dummy argument 1
of the associated actual procedure differ from the characteristics of dummy
argument 1 of the dummy procedure. (12.2)   [TWO]
  call bar(two)
-----------^

I would change this bug's status from UNCONFIRMED to NEW, but apparently I
don't have the "canconfirm" permission.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2008-04-09 18:49 -------
> In this test case both arrays are explicit-sized, and even have the same size,
> but their upper and lower bounds are shifted. gfortran currently does not even
> check if both arrays have the same size, only their ranks are compared.

I think procedures with explicit-shape arguments with the same shape/size but
only different bounds should be conformable.

The only real problem is assumed-shape vs. the rest (explict, assumed-size,
...). Ok, if an explicit size is given, the sizes should match, but arguments
of the dummy/actual function like "integer :: foo(*)" and bar(1:2) and
foobar(3000:3001) should all be conformable.
Similarly, I think, also foo(1:), bar(:) and foobar(-300:) should be
conformable.

(I cannot really pinpoint it in the standard, but I'm convinced that this is
the case; when I have time, I will re-read the standard and try to produce a
proper reference.)
* I use "manner" as "kind" and "type" have a special Fortran meaning.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-04-09 18:49:31
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[jaydub66 at gmail dot com]

------- Comment #4 from jaydub66 at gmail dot com  2008-04-10 21:09 -------
To me it's also not completely clear what the standard says on this, but the
way to fix it would probably be to insert some additional check into
operator_correspondence (interface.c), where currently only the type and rank
of the arguments is checked.


To require full equality of all array borders (as suggested in my comment #2),
one could simply add

      if (!gfc_compare_array_spec (f1->sym->as, f2->sym->as))
        return 1;

into the above mentioned routine. This would result in gfortran behaving the
same way as ifort in this case, may it be standard-conforming or not.


If on the other hand Tobias is right in the assumption he made in comment #3,
then one could something along the lines of

  if (f1->sym->as->type != f2->sym->as->type)
    return 1;

to require only the array types to be equal, or something similar to at least
prevent assumed-shape arrays from being passed instead of eplicit-shape arrays.


My feeling is that at least the array size should match for explicit-shape
arrays, but this is just a feeling and I couldn't find anything in the standard
to confirm this.

I'm not sure if the changes I'm suggesting would interfere with any other case
where 'operator_correspondence' is called, but at least they don't seem to
trigger any regressions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2008-04-11 07:45 -------
> If on the other hand Tobias is right in the assumption he made in comment #3,
> then one could something along the lines of
>   if (f1->sym->as->type != f2->sym->as->type)

I would not be surprised if foo(*) and foo(4) are allowed and then your test
rejects too much.

> My feeling is that at least the array size should match for explicit-shape
> arrays,

I'm not sure about that part; one can create "valid" (i.e. working) programs
which violate this (e.g.: array(5), array(10), but only accessing 1 to 5). We
should check what the standard says about this. I think it is formally invalid
to do so; if we decide to allow it, at least a warning should be printed.

(At the end one needs to carefully read the standard, unfortunately, I do not
have much time the next two, three weeks. One could also ask at
comp.lang.fortran.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831

[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #6 from janus at gcc dot gnu.org 2011-09-10 10:18:58 UTC ---
(In reply to comment #0)
> Fortran 2003's "12.4.1.3 Actual arguments associated with dummy procedure
> entities" has about this:
> 
> "If the interface of the dummy argument is explicit, the characteristics listed
> in 12.2 shall be the same for the associated actual argument and the
> corresponding dummy argument, except that a pure actual argument may be
> associated with a dummy argument that is not pure and an elemental intrinsic
> actual procedure may be associated with a dummy procedure (which is prohibited
> from being elemental)."


Note: The same restrictions are already listed in F95's chapter 12.4.1.2, as
well as F08's chapter 12.5.2.9. At first sight there are no differences between
the different versions of the standard in the quoted passage.