Bug 42045 - [F03] passing a procedure pointer component to a procedure pointer dummy
Summary: [F03] passing a procedure pointer component to a procedure pointer dummy
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: rejects-valid
Depends on:
Blocks:
 
Reported: 2009-11-14 18:30 UTC by janus
Modified: 2009-11-24 08:18 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-11-20 17:24:11


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description janus 2009-11-14 18:30:50 UTC
The following was reported by John McFarland:

PROGRAM prog
 TYPE object
  PROCEDURE(), POINTER, NOPASS :: f
 END TYPE object
 TYPE container
  TYPE (object), POINTER :: o(:)
 END TYPE container
 TYPE (container) :: c
 TYPE (object) :: o1, o2
 PROCEDURE(), POINTER :: f => NULL()
 o1%f => f
 ! This works
 CALL set_func(o2,f)
 ! Here the compiler says the second argument has the wrong type?
 CALL set_func(o2,o1%f)
 ! Same error as above, but want to make sure this case works too
 ALLOCATE( c%o(5) )
 c%o(5)%f => f
 CALL set_func(o2,c%o(5)%f)
CONTAINS
 SUBROUTINE set_func(o,f)
  TYPE (object) :: o
  PROCEDURE(), POINTER :: f
  o%f => f
 END SUBROUTINE set_func
END PROGRAM prog


This program is rejected with 

test.f90:15.18:

 CALL set_func(o2,o1%f)
                  1
Error: Type mismatch in argument 'f' at (1); passed REAL(4) to UNKNOWN
test.f90:19.18:

 CALL set_func(o2,c%o(5)%f)
                  1
Error: Type mismatch in argument 'f' at (1); passed REAL(4) to UNKNOWN


In contrast to what these error messages say, the program seems to be valid.
Comment 1 janus 2009-11-15 12:39:22 UTC
Cf. also PR39997, the discussion in http://j3-fortran.org/pipermail/j3/2009-May/002736.html and follow-ups, and http://www.j3-fortran.org/doc/year/09/09-236r1.txt (which seems to confirm that the test case is valid).
Comment 2 janus 2009-11-15 12:50:11 UTC
With the following patch, the errors go away:

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c       (revision 154188)
+++ gcc/fortran/resolve.c       (working copy)
@@ -10217,11 +10217,6 @@ resolve_fl_derived (gfc_symbol *sym)
              return FAILURE;
            }
        }
-      else if (c->attr.proc_pointer && c->ts.type == BT_UNKNOWN)
-       {
-         c->ts = *gfc_get_default_type (c->name, NULL);
-         c->attr.implicit_type = 1;
-       }

       /* Procedure pointer components: Check PASS arg.  */
       if (c->attr.proc_pointer && !c->tb->nopass && c->tb->pass_arg_num == 0)


but then one gets:

internal compiler error: in gfc_walk_variable_expr, at fortran/trans-array.c:6308
Comment 3 janus 2009-11-15 14:24:12 UTC
(In reply to comment #2)
> internal compiler error: in gfc_walk_variable_expr, at
> fortran/trans-array.c:6308

The ICE goes away when adding this:

Index: gcc/fortran/resolve.c                    
===================================================================
--- gcc/fortran/resolve.c       (revision 154188)                  
+++ gcc/fortran/resolve.c       (working copy)                     
@@ -1321,6 +1321,8 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p
                e->rank = comp->as->rank;                               
              e->expr_type = EXPR_FUNCTION;                             
            }                                                           
+         if (gfc_resolve_expr (e) == FAILURE)                          
+           return FAILURE;                                             
          goto argument_list;                                           
        }                


The patch in comment #2 however triggers the following regressions:

FAIL: gfortran.dg/proc_ptr_comp_12.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_18.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_19.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_comp_2.f90  -O0  (test for excess errors)
Comment 4 janus 2009-11-20 17:24:11 UTC
With this patch

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 154369)
+++ gcc/fortran/resolve.c	(working copy)
@@ -1321,6 +1321,8 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p
 		e->rank = comp->as->rank;
 	      e->expr_type = EXPR_FUNCTION;
 	    }
+	  if (gfc_resolve_expr (e) == FAILURE)                          
+	    return FAILURE; 
 	  goto argument_list;
 	}
 
@@ -2519,6 +2521,10 @@ resolve_function (gfc_expr *expr)
   if (expr->symtree)
     sym = expr->symtree->n.sym;
 
+  /* If this is a procedure pointer component, it has already been resolved.  */
+  if (gfc_is_proc_ptr_comp (expr, NULL))
+    return SUCCESS;
+  
   if (sym && sym->attr.intrinsic
       && resolve_intrinsic (sym, &expr->where) == FAILURE)
     return FAILURE;
@@ -10219,8 +10225,9 @@ resolve_fl_derived (gfc_symbol *sym)
 	}
       else if (c->attr.proc_pointer && c->ts.type == BT_UNKNOWN)
 	{
-	  c->ts = *gfc_get_default_type (c->name, NULL);
-	  c->attr.implicit_type = 1;
+	  /* Since PPCs are not implicitly typed, a PPC without an explicit
+	     interface must be a subroutine.  */
+	  gfc_add_subroutine (&c->attr, c->name, &c->loc);
 	}
 
       /* Procedure pointer components: Check PASS arg.  */


the only remaining regression is proc_ptr_comp_2.f90, which is invalid with respect to the interpretation in http://www.j3-fortran.org/doc/year/09/09-236r1.txt.
Comment 5 janus 2009-11-24 08:16:45 UTC
Subject: Bug 42045

Author: janus
Date: Tue Nov 24 08:16:32 2009
New Revision: 154492

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

	PR fortran/42045
	* resolve.c (resolve_actual_arglist): Make sure procedure pointer
	actual arguments are resolved correctly.
	(resolve_function): An EXPR_FUNCTION which is a procedure pointer
	component, has already been resolved.
	(resolve_fl_derived): Procedure pointer components should not be
	implicitly typed.

2009-11-24  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/42045
	* gfortran.dg/proc_ptr_comp_2.f90: Correct invalid test case.
	* gfortran.dg/proc_ptr_comp_3.f90: Extended test case.
	* gfortran.dg/proc_ptr_comp_24.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_24.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_2.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_3.f90

Comment 6 janus 2009-11-24 08:18:59 UTC
Fixed with r154492. Closing.