[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