Bug 40541 - Assignment checking for proc-pointer => proc-ptr-returning-function()
Summary: Assignment checking for proc-pointer => proc-ptr-returning-function()
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-06-24 12:59 UTC by Tobias Burnus
Modified: 2009-06-26 22:12 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-06-24 16:43:47


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2009-06-24 12:59:02 UTC
Found while looking at PR 39997. The following is not checked. The reason is that the check contains:

  if (rvalue->expr_type == EXPR_VARIABLE

while the example has EXPR_FUNCTION


program test
  procedure(real), pointer :: p
  p => f()  ! << Invalid f() returns a LOGICAL(1) function, but p is a REAL one
contains
 function f()
   pointer :: f
   interface
     logical(1) function f()
     end function
   end interface
   f = .true._1
 end function f
end program test

 * * *

Maybe PR 39997 (comment 3) item 3 can be fixed at the same time. One needs just to add:
  If( RHS is a function && LHS is untyped) {
    implicitly type proc pointer on the LHS
  }
before the subroutine/function check is done.
Comment 1 janus 2009-06-24 16:43:46 UTC
This is easily fixed by the following patchlet (I had just forgotten about this case):

Index: gcc/fortran/expr.c
===================================================================
--- gcc/fortran/expr.c	(revision 148905)
+++ gcc/fortran/expr.c	(working copy)
@@ -3189,10 +3189,14 @@
       /* TODO: Enable interface check for PPCs.  */
       if (is_proc_ptr_comp (rvalue, NULL))
 	return SUCCESS;
-      if (rvalue->expr_type == EXPR_VARIABLE
-	  && !gfc_compare_interfaces (lvalue->symtree->n.sym,
-				      rvalue->symtree->n.sym, 0, 1, err,
-				      sizeof(err)))
+      if ((rvalue->expr_type == EXPR_VARIABLE
+	   && !gfc_compare_interfaces (lvalue->symtree->n.sym,
+				       rvalue->symtree->n.sym, 0, 1, err,
+				       sizeof(err)))
+	  || (rvalue->expr_type == EXPR_FUNCTION
+	      && !gfc_compare_interfaces (lvalue->symtree->n.sym,
+					  rvalue->symtree->n.sym->result, 0, 1,
+					  err, sizeof(err))))
 	{
 	  gfc_error ("Interface mismatch in procedure pointer assignment "
 		     "at %L: %s", &rvalue->where, err);

However, there remains one problem (aka PR 39695): The error message for the code in comment #0 has the wrong name:

  p => f()
       1
Error: Interface mismatch in procedure pointer assignment at (1): Type/kind mismatch in return value of 'ppr@'
Comment 2 janus 2009-06-26 22:11:32 UTC
Subject: Bug 40541

Author: janus
Date: Fri Jun 26 22:11:15 2009
New Revision: 148996

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148996
Log:
2009-06-26  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/39997
	PR fortran/40541
	* decl.c (add_hidden_procptr_result): Copy the typespec to the hidden
	result.
	* expr.c (gfc_check_pointer_assign): Enable interface check for
	procedure pointer assignments where the rhs is a function returning a
	procedure pointer.
	* resolve.c (resolve_symbol): If an external procedure with unspecified
	return type can not be implicitly typed, it must be a subroutine.


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

	PR fortran/39997
	PR fortran/40541
	* gfortran.dg/proc_ptr_15.f90: Fixed and extended.
	* gfortran.dg/proc_ptr_common_1.f90: Fixed invalid test case.
	* gfortran.dg/proc_ptr_result_1.f90: Ditto.
	* gfortran.dg/proc_ptr_result_5.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_15.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_common_1.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_1.f90

Comment 3 janus 2009-06-26 22:12:51 UTC
Fixed in r148996. Closing.