Bug 41733 - Proc-pointer conformance checks: Elemental-proc-ptr => non-elemental-proc
Summary: Proc-pointer conformance checks: Elemental-proc-ptr => non-elemental-proc
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: accepts-invalid
Depends on:
Blocks:
 
Reported: 2009-10-16 19:49 UTC by Tobias Burnus
Modified: 2011-09-22 09:40 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-09-15 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2009-10-16 19:49:02 UTC
Pointed out by James Van Buskirk in http://groups.google.com/group/comp.lang.fortran/msg/c96779deea345264
in the thread
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/da1feef5e8c9ed9a

Gfortran misses several proc-pointer checks. Cf. also PR 41724.
Comment 1 Tobias Burnus 2009-10-16 20:35:19 UTC
The first example,
   procedure(fun), pointer :: f
   f => my_dcos
   write(*,*) f(x)
looks fine to me. "fun" is elemental - and my_dcos is also elemental.

The second example is wrong: "fun" is elemental, but "my_dcos" is not thus
   f => my_dcos
is invalid per F2003, 7.4.2.2 Procedure 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."

The third example looks OK again - actually, it is the same as the first, except that one uses an intrinsic elemental procedure (dcos).

Test case for the second example:

 module funcs
   implicit none
   integer, parameter :: dp = kind(1.0d0)
   abstract interface
      elemental function fun(x)
         import
         implicit none
         real(dp), intent(in) :: x
         real(dp) fun
      end function fun
   end interface
   contains
  function my_dcos(x)
    integer, parameter :: dp = kind(1.0d0)
    real(dp), intent(in) :: x
    real(dp) :: my_dcos
    my_dcos = cos(x)
  end function
end module funcs

program start
   use funcs
   implicit none
   procedure(fun), pointer :: f
   real(dp) x(3)
   x = [1,2,3]
   f => my_dcos
   write(*,*) f(x)
end program start
Comment 2 Tobias Burnus 2009-10-17 19:07:45 UTC
There is the following additional restriction, which I could not find (Thanks James!):

C728 (R742) The proc-target shall not be a nonintrinsic elemental procedure.
Comment 3 janus 2011-09-15 19:32:59 UTC
(In reply to comment #2)
> C728 (R742) The proc-target shall not be a nonintrinsic elemental procedure.

Here is a simple patch for this constraint:


Index: gcc/fortran/expr.c
===================================================================
--- gcc/fortran/expr.c	(revision 178888)
+++ gcc/fortran/expr.c	(working copy)
@@ -3448,6 +3448,14 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
 			      rvalue->symtree->name, &rvalue->where) == FAILURE)
 	    return FAILURE;
 	}
+      /* Check for F08:C730.  */
+      if (attr.elemental && !attr.intrinsic)
+	{
+	  gfc_error ("Nonintrinsic elemental procedure '%s' is invalid "
+		     "in procedure pointer assigment at %L",
+		     rvalue->symtree->name, &rvalue->where);
+	  return FAILURE;
+	}
 
       /* Ensure that the calling convention is the same. As other attributes
 	 such as DLLEXPORT may differ, one explicitly only tests for the


and a minimal test case:


  implicit none
  procedure(my_dcos), pointer :: f
  f => my_dcos
contains
  real elemental function my_dcos(x)
    real, intent(in) :: x
    my_dcos = cos(x)
  end function
end
Comment 4 janus 2011-09-15 19:47:21 UTC
Also we need to check for the following F08 constraints:


"12.5.2.9 Actual arguments associated with dummy procedure entities
If the interface of a dummy procedure is explicit, its characteristics as a procedure (12.3.1) shall be the same as those of its effective argument, except that a pure effective 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 cannot be elemental)."


and


"7.2.2.4 Procedure pointer assignment
3 If the pointer object has an explicit interface, its characteristics shall be the same as the pointer target except that the pointer target may be pure even if the pointer object is not pure and the pointer target may be an elemental intrinsic procedure even if the pointer object is not elemental."
Comment 5 janus 2011-09-22 09:32:14 UTC
Author: janus
Date: Thu Sep 22 09:32:11 2011
New Revision: 179080

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179080
Log:
2011-09-22  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/41733
	* expr.c (gfc_check_pointer_assign): Check for nonintrinsic elemental
	procedures.
	* interface.c (gfc_compare_interfaces): Rename 'intent_flag'. Check
	for PURE and ELEMENTAL attributes.
	(compare_actual_formal): Remove pureness check here.


2011-09-22  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/41733
	* gfortran.dg/impure_actual_1.f90: Modified error message.
	* gfortran.dg/proc_ptr_32.f90: New.
	* gfortran.dg/proc_ptr_33.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_32.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_33.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/interface.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/impure_actual_1.f90
Comment 6 janus 2011-09-22 09:40:07 UTC
r179080 should fix all issues in the c.l.f. thread. Closing as fixed.