[Patch, Fortran] PR 36947/40039: Better error messages for dummy procedures and check for OPTIONAL

Janus Weil janus@gcc.gnu.org
Fri Jun 12 15:48:00 GMT 2009


2009/5/25 Tobias Burnus <burnus@net-b.de>:
>> "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, ..."
>
> I think passing an actual argument with an implicit interface to
> an explicit-interface dummy is also allowed. If the explicit
> argument were required, the standard had written it explicitly.

Attached is a new version of the patch, which retreats to the old
behaviour in this matter. In addition I fixed a smaller bug that
Tobias reported privately and added another test case. I also made
sure that it still passes the testsuite without failures.

Tobi's other comments I will take care of in a follow-up patch (pure,
elemental, recursive checking etc).

Ok for trunk?

Cheers,
Janus


2009-06-12  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/36947
	PR fortran/40039
	* expr.c (gfc_check_pointer_assign): Call 'gfc_compare_interfaces' with
	error message.
	* gfortran.h (gfc_compare_interfaces): Additional argument.
	* interface.c (operator_correspondence): Removed.
	(gfc_compare_interfaces): Additional argument to return error message.
	Directly use the code from 'operator_correspondence' instead of calling
	the function. Check for OPTIONAL. Some rearrangements.
	(check_interface1): Call 'gfc_compare_interfaces' without error message.
	(compare_parameter): Call 'gfc_compare_interfaces' with error message.
	* resolve.c (check_generic_tbp_ambiguity): Call 'gfc_compare_interfaces'
	without error message.


2009-06-12  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/36947
	PR fortran/40039
	* gfortran.dg/dummy_procedure_1.f90: Extended test case.
	* gfortran.dg/interface_20.f90: Modified error messages.
	* gfortran.dg/interface_21.f90: Ditto.
	* gfortran.dg/interface_26.f90: Ditto.
	* gfortran.dg/interface_27.f90: Ditto.
	* gfortran.dg/interface_28.f90: Extended test case.
	* gfortran.dg/interface_29.f90: New.
	* gfortran.dg/proc_decl_7.f90: Modified error messages.
	* gfortran.dg/proc_decl_8.f90: Ditto.
	* gfortran.dg/proc_ptr_11.f90: Ditto.
	* gfortran.dg/proc_ptr_15.f90: Ditto.


> I think some other checks should still be added, e.g.
>
> a) PUREness check (see example below); passing/assigning
>   a pure to a non-pure dummy/proc-pointer is OK; doing vice versa
>   is not.
>
> See "12.4.1.3" (dummy-actual arguments)
>  "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)."
> And also "7.4.2.2" (proc-pointer assignment):
>  "If proc-pointer-object has an explicit interface, its
>  characteristics shall be the same as proc-target except that
>  proc-target may be pure even if proc-pointer-object is not pure
>  and proc-target may be an elemental intrinsic procedure even
>  if proc-pointer-object is not elemental."
>
> b) Similarly for ELEMENTAL. For proc-pointer assignments, use the
>   first example with PURE changed to ELEMENTAL. That non-intrinsic
>   elementals are not allowed as actual argument, is already checked
>   for (cf. C1228). Except of the remark in parentheses I could not
>   find in F2003/F2008 anything which prohibits ELEMENTAL for the
>   dummy argument; however, the parentheses is normative. Maybe one
>   should re-check the standard before adding an error check (see
>   example below).
>
> c) One needs to go recursively over the arguments as the second
>   example below shows.
>
>
> Tobias
>
>
> PROGRAM PURENESS
> implicit none
> interface
>  subroutine one(a,b,c,d,e,f,g,h,i)
>    implicit none
>    integer,intent(in) :: a,b,c,d,e,f,g,h,i
>  end subroutine one
>  pure subroutine two(a,b,c,d,e,f,g,h,i)
>    implicit none
>    integer,intent(in) :: a,b,c,d,e,f,g,h,i
>  end subroutine two
> end interface
> procedure(two), pointer :: ptr
> ptr => one  ! Invalid: (pure) => (unpure)
> end program pureness
>
>
> program RecursiveInterface
>  interface
>    subroutine a(x)
>      real :: x
>    end subroutine a
>    subroutine b(a)
>      integer :: a
>    end subroutine b
>    subroutine c(f)
>      procedure(a) :: f
>    end subroutine c
>    subroutine d(f)
>      procedure(b) :: f
>    end subroutine d
>    subroutine e(f)
>     procedure(c) :: f
>    end subroutine e
>  end interface
>  call e(d) ! Argument (dummy subroutine) d has an integer argument
>            ! but e's f expects a real argument
> end program RecursiveInterface
>
>
> interface
>  elemental subroutine a()  ! Expected: Warning: ELEMENTAL procedure
>                            ! without arguments
>  ! (Having ELEMENTAL does not make much sense without arguments, but
>  !  it is valid)
>  end subroutine a
>  subroutine sub(f)
>    interface
>      elemental subroutine f(a)
>        integer,intent(IN) :: a
>      end subroutine f
>    end interface
> ! Invalid per 12.4.1.3?
> ! "an elemental intrinsic actual procedure may be associated with
> !  a dummy procedure (which is prohibited from being elemental)."
> !                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ! Todo: Find it elsewhere in the standard - or in the corrigenda;
> !       other compilers accept it. However, the part above is normative
>  end subroutine sub
> end interface
> end program elementalCheck
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr40039_2.diff
Type: text/x-patch
Size: 16674 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20090612/1644155b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interface_29.f90
Type: text/x-fortran
Size: 1158 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20090612/1644155b/attachment-0001.bin>


More information about the Fortran mailing list