[Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER

[Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

Hi all,

the attached patch fixes the behavior of C_F_PROCPOINTER if its
procptr argument is itself a dummy argument of another procedure. For
this case I added an additional 'build_fold_indirect_ref_loc', and I
also removed an unneeded 'tmp' variable. The patch was regtested on
x86_64-unknown-linux-gnu with no failures. Ok for trunk?

Two side-notes:

1) About the wrong static decl (cf. comments #3 and #5): I currently
have no idea how this comes about, and why the static prototype is
different from the actual declaration of the function. Does anyone
have an idea?

2) Once again I stumbled over the fact that the ISO_C_BINDING
intrinsics are handled in gfc_conv_procedure_call, in contrast to all
the other intrinsics, which are translated in trans-intrinsic.c. It
seems to me that gfc_conv_procedure_call is not a particularly good
place for this, as it is already a *huge* routine (several hundred
lines), even without the additional clobbering due to these
intrinsics. Is there a special reason that this is done in this very
place, or should we rather move this code to trans-intrinsic.c? (If
the latter, I would open a cleanup PR for this.)

Cheers,
Janus


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

	PR fortran/42072
	* trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer
	dummies which are passed to C_F_PROCPOINTER.


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

	PR fortran/42072
	* gfortran.dg/proc_ptr_8.f90: Extended.

[-- Attachment #2: pr42072.diff --]
[-- Type: text/x-diff, Size: 1928 bytes --]

Index: gcc/testsuite/gfortran.dg/proc_ptr_8.f90
===================================================================
--- gcc/testsuite/gfortran.dg/proc_ptr_8.f90	(revision 154242)
+++ gcc/testsuite/gfortran.dg/proc_ptr_8.f90	(working copy)
@@ -23,12 +23,23 @@ MODULE X
 END MODULE X
 
 USE X
-PROCEDURE(mytype), POINTER :: ptype
+PROCEDURE(mytype), POINTER :: ptype,ptype2
 
 CALL init()
 CALL C_F_PROCPOINTER(funpointer,ptype)
 if (ptype(3) /= 9) call abort()
 
+! the stuff below was added with PR 42072
+call setpointer(ptype2)
+if (ptype2(4) /= 12) call abort()
+
+contains
+
+  subroutine setpointer (p)
+    PROCEDURE(mytype), POINTER :: p
+    CALL C_F_PROCPOINTER(funpointer,p)
+  end subroutine
+
 END
 
 ! { dg-final { cleanup-modules "X" } }
Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c	(revision 154242)
+++ gcc/fortran/trans-expr.c	(working copy)
@@ -2640,14 +2640,17 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
 	  gfc_conv_expr (&fptrse, arg->next->expr);
 	  gfc_add_block_to_block (&se->pre, &fptrse.pre);
 	  gfc_add_block_to_block (&se->post, &fptrse.post);
+	  
+	  if (arg->next->expr->symtree->n.sym->attr.proc_pointer
+	      && arg->next->expr->symtree->n.sym->attr.dummy)
+	    fptrse.expr = build_fold_indirect_ref_loc (input_location,
+						       fptrse.expr);
+	  
+	  se->expr = fold_build2 (MODIFY_EXPR, TREE_TYPE (fptrse.expr),
+				  fptrse.expr,
+				  fold_convert (TREE_TYPE (fptrse.expr),
+						cptrse.expr));
 
-	  if (gfc_is_proc_ptr_comp (arg->next->expr, NULL))
-	    tmp = gfc_get_ppc_type (arg->next->expr->ref->u.c.component);
-	  else
-	    tmp = TREE_TYPE (arg->next->expr->symtree->n.sym->backend_decl);
-	  se->expr = fold_build2 (MODIFY_EXPR, tmp, fptrse.expr,
-				  fold_convert (tmp, cptrse.expr));
-
 	  return 0;
 	}
       else if (sym->intmod_sym_id == ISOCBINDING_ASSOCIATED)

Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER

[Paul Richard Thomas]

Janus,

> x86_64-unknown-linux-gnu with no failures. Ok for trunk?

OK for trunk (and fortran-dev :-))
>
> Two side-notes:
>
> 1) About the wrong static decl (cf. comments #3 and #5): I currently
> have no idea how this comes about, and why the static prototype is
> different from the actual declaration of the function. Does anyone
> have an idea?

That is indeed very odd and clearly incorrect.  Could you please raise
a new PR for this?

>
> 2) Once again I stumbled over the fact that the ISO_C_BINDING
> intrinsics are handled in gfc_conv_procedure_call, in contrast to all
> the other intrinsics, which are translated in trans-intrinsic.c. It
> seems to me that gfc_conv_procedure_call is not a particularly good
> place for this, as it is already a *huge* routine (several hundred
> lines), even without the additional clobbering due to these
> intrinsics. Is there a special reason that this is done in this very
> place, or should we rather move this code to trans-intrinsic.c? (If
> the latter, I would open a cleanup PR for this.)


I have been eying gfc_conv_procedure_call with a view to breaking out
the various sections into functions so that its structure becomes
apparent once more.  I have not thought about it much and would
certainly applaud anybody taking it upon themselves to do it.  As
usual, such a task requires identifying the seams such that argument
lists do not become as long as the functions being replaced :-)  As
for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have
any opinion, other than to note that the "normal" intrinsics are
different beasts altogether.

Thanks for the fix

Paul


> 2009-11-17  Janus Weil  <janus@gcc.gnu.org>
>
>        PR fortran/42072
>        * trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer
>        dummies which are passed to C_F_PROCPOINTER.
>
>
> 2009-11-17  Janus Weil  <janus@gcc.gnu.org>
>
>        PR fortran/42072
>        * gfortran.dg/proc_ptr_8.f90: Extended.
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER

[Tobias Burnus]

On 11/18/2009 11:28 AM, Paul Richard Thomas wrote:
> x86_64-unknown-linux-gnu with no failures. Ok for trunk?
>   
> OK for trunk (and fortran-dev :-))
>   
fortran-dev should automatically pick up the changes from the trunk -
the next time someone does a merge.

I just merged the trunk into fortran-dev as Rev. 154286. The branch
contains all changes from the trunk up to 154283. (Current is Rev. 154286.)

Tobias

Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER

[Janus Weil]

>> x86_64-unknown-linux-gnu with no failures. Ok for trunk?
>
> OK for trunk (and fortran-dev :-))

Thanks. Committed as r154292.


> As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have
> any opinion, other than to note that the "normal" intrinsics are
> different beasts altogether.

Why are they so much different? Regarding the translation, we do
pretty much the same for the ISO_C_BINDING intrinsics as we do for
some of the others, namely replacing the call by some inline code.
E.g. for C_F_PROCPOINTER, we just put in a simple pointer assignment.

Cheers,
Janus


>> 2009-11-17  Janus Weil  <janus@gcc.gnu.org>
>>
>>        PR fortran/42072
>>        * trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer
>>        dummies which are passed to C_F_PROCPOINTER.
>>
>>
>> 2009-11-17  Janus Weil  <janus@gcc.gnu.org>
>>
>>        PR fortran/42072
>>        * gfortran.dg/proc_ptr_8.f90: Extended.
>>
>
>
>
> --
> The knack of flying is learning how to throw yourself at the ground and miss.
>       --Hitchhikers Guide to the Galaxy
>

Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

>> As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have
>> any opinion, other than to note that the "normal" intrinsics are
>> different beasts altogether.
>
> Why are they so much different? Regarding the translation, we do
> pretty much the same for the ISO_C_BINDING intrinsics as we do for
> some of the others, namely replacing the call by some inline code.
> E.g. for C_F_PROCPOINTER, we just put in a simple pointer assignment.

Well, ok, I can see that they are handled a bit differently in some ways.

The least thing one could do would be to just separate out the
ISO_C_BINDING special handling code from gfc_conv_procedure_call, to
make it less of a monster.

The attachted patch does this by just putting the ISO_C_BINDING stuff
into a separate routine. And it does so without introducing any
regressions in the testsuite (i just checked). Should I commit this to
trunk?

Cheers,
Janus

[-- Attachment #2: pr42072_2.diff --]
[-- Type: text/x-diff, Size: 10035 bytes --]

Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c	(revision 154292)
+++ gcc/fortran/trans-expr.c	(working copy)
@@ -2533,6 +2533,149 @@ conv_arglist_function (gfc_se *se, gfc_expr *expr,
 }
 
 
+/* The following routine generates code for the intrinsic
+   procedures from the ISO_C_BINDING module:
+    * C_LOC           (function)
+    * C_FUNLOC        (function)
+    * C_F_POINTER     (subroutine)
+    * C_F_PROCPOINTER (subroutine)
+    * C_ASSOCIATED    (function)
+   One exception which is not handled here is C_F_POINTER with non-scalar
+   arguments. Returns 1 if the call was replaced by inline code (else: 0).  */
+
+static int
+conv_isocbinding_procedure (gfc_se * se, gfc_symbol * sym,
+			    gfc_actual_arglist * arg)
+{
+  gfc_symbol *fsym;
+  gfc_ss *argss;
+    
+  if (sym->intmod_sym_id == ISOCBINDING_LOC)
+    {
+      if (arg->expr->rank == 0)
+	gfc_conv_expr_reference (se, arg->expr);
+      else
+	{
+	  int f;
+	  /* This is really the actual arg because no formal arglist is
+	      created for C_LOC.	 */
+	  fsym = arg->expr->symtree->n.sym;
+
+	  /* We should want it to do g77 calling convention.  */
+	  f = (fsym != NULL)
+	    && !(fsym->attr.pointer || fsym->attr.allocatable)
+	    && fsym->as->type != AS_ASSUMED_SHAPE;
+	  f = f || !sym->attr.always_explicit;
+      
+	  argss = gfc_walk_expr (arg->expr);
+	  gfc_conv_array_parameter (se, arg->expr, argss, f,
+				    NULL, NULL, NULL);
+	}
+
+      /* TODO -- the following two lines shouldn't be necessary, but
+	they're removed a bug is exposed later in the codepath.
+	This is workaround was thus introduced, but will have to be
+	removed; please see PR 35150 for details about the issue.  */
+      se->expr = convert (pvoid_type_node, se->expr);
+      se->expr = gfc_evaluate_now (se->expr, &se->pre);
+
+      return 1;
+    }
+  else if (sym->intmod_sym_id == ISOCBINDING_FUNLOC)
+    {
+      arg->expr->ts.type = sym->ts.u.derived->ts.type;
+      arg->expr->ts.f90_type = sym->ts.u.derived->ts.f90_type;
+      arg->expr->ts.kind = sym->ts.u.derived->ts.kind;
+      gfc_conv_expr_reference (se, arg->expr);
+  
+      return 1;
+    }
+  else if ((sym->intmod_sym_id == ISOCBINDING_F_POINTER
+	      && arg->next->expr->rank == 0)
+	    || sym->intmod_sym_id == ISOCBINDING_F_PROCPOINTER)
+    {
+      /* Convert c_f_pointer if fptr is a scalar
+	  and convert c_f_procpointer.  */
+      gfc_se cptrse;
+      gfc_se fptrse;
+
+      gfc_init_se (&cptrse, NULL);
+      gfc_conv_expr (&cptrse, arg->expr);
+      gfc_add_block_to_block (&se->pre, &cptrse.pre);
+      gfc_add_block_to_block (&se->post, &cptrse.post);
+
+      gfc_init_se (&fptrse, NULL);
+      if (sym->intmod_sym_id == ISOCBINDING_F_POINTER
+	  || gfc_is_proc_ptr_comp (arg->next->expr, NULL))
+	fptrse.want_pointer = 1;
+
+      gfc_conv_expr (&fptrse, arg->next->expr);
+      gfc_add_block_to_block (&se->pre, &fptrse.pre);
+      gfc_add_block_to_block (&se->post, &fptrse.post);
+      
+      if (arg->next->expr->symtree->n.sym->attr.proc_pointer
+	  && arg->next->expr->symtree->n.sym->attr.dummy)
+	fptrse.expr = build_fold_indirect_ref_loc (input_location,
+						    fptrse.expr);
+      
+      se->expr = fold_build2 (MODIFY_EXPR, TREE_TYPE (fptrse.expr),
+			      fptrse.expr,
+			      fold_convert (TREE_TYPE (fptrse.expr),
+					    cptrse.expr));
+
+      return 1;
+    }
+  else if (sym->intmod_sym_id == ISOCBINDING_ASSOCIATED)
+    {
+      gfc_se arg1se;
+      gfc_se arg2se;
+
+      /* Build the addr_expr for the first argument.  The argument is
+	  already an *address* so we don't need to set want_pointer in
+	  the gfc_se.  */
+      gfc_init_se (&arg1se, NULL);
+      gfc_conv_expr (&arg1se, arg->expr);
+      gfc_add_block_to_block (&se->pre, &arg1se.pre);
+      gfc_add_block_to_block (&se->post, &arg1se.post);
+
+      /* See if we were given two arguments.  */
+      if (arg->next == NULL)
+	/* Only given one arg so generate a null and do a
+	    not-equal comparison against the first arg.  */
+	se->expr = fold_build2 (NE_EXPR, boolean_type_node, arg1se.expr,
+				fold_convert (TREE_TYPE (arg1se.expr),
+					      null_pointer_node));
+      else
+	{
+	  tree eq_expr;
+	  tree not_null_expr;
+	  
+	  /* Given two arguments so build the arg2se from second arg.  */
+	  gfc_init_se (&arg2se, NULL);
+	  gfc_conv_expr (&arg2se, arg->next->expr);
+	  gfc_add_block_to_block (&se->pre, &arg2se.pre);
+	  gfc_add_block_to_block (&se->post, &arg2se.post);
+
+	  /* Generate test to compare that the two args are equal.  */
+	  eq_expr = fold_build2 (EQ_EXPR, boolean_type_node,
+				  arg1se.expr, arg2se.expr);
+	  /* Generate test to ensure that the first arg is not null.  */
+	  not_null_expr = fold_build2 (NE_EXPR, boolean_type_node,
+					arg1se.expr, null_pointer_node);
+
+	  /* Finally, the generated test must check that both arg1 is not
+	      NULL and that it is equal to the second arg.  */
+	  se->expr = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
+				  not_null_expr, eq_expr);
+	}
+
+      return 1;
+    }
+    
+  return 0;
+}
+
+
 /* Generate code for a procedure call.  Note can return se->post != NULL.
    If se->direct_byref is set then se->expr contains the return parameter.
    Return nonzero, if the call has alternate specifiers.
@@ -2576,131 +2719,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
   len = NULL_TREE;
   gfc_clear_ts (&ts);
 
-  if (sym->from_intmod == INTMOD_ISO_C_BINDING)
-    {
-      if (sym->intmod_sym_id == ISOCBINDING_LOC)
-	{
-	  if (arg->expr->rank == 0)
-	    gfc_conv_expr_reference (se, arg->expr);
-	  else
-	    {
-	      int f;
-	      /* This is really the actual arg because no formal arglist is
-		 created for C_LOC.	 */
-	      fsym = arg->expr->symtree->n.sym;
+  if (sym->from_intmod == INTMOD_ISO_C_BINDING
+      && conv_isocbinding_procedure (se, sym, arg))
+    return 0;
 
-	      /* We should want it to do g77 calling convention.  */
-	      f = (fsym != NULL)
-		&& !(fsym->attr.pointer || fsym->attr.allocatable)
-		&& fsym->as->type != AS_ASSUMED_SHAPE;
-	      f = f || !sym->attr.always_explicit;
-	  
-	      argss = gfc_walk_expr (arg->expr);
-	      gfc_conv_array_parameter (se, arg->expr, argss, f,
-					NULL, NULL, NULL);
-	    }
-
-	  /* TODO -- the following two lines shouldn't be necessary, but
-	    they're removed a bug is exposed later in the codepath.
-	    This is workaround was thus introduced, but will have to be
-	    removed; please see PR 35150 for details about the issue.  */
-	  se->expr = convert (pvoid_type_node, se->expr);
-	  se->expr = gfc_evaluate_now (se->expr, &se->pre);
-
-	  return 0;
-	}
-      else if (sym->intmod_sym_id == ISOCBINDING_FUNLOC)
-	{
-	  arg->expr->ts.type = sym->ts.u.derived->ts.type;
-	  arg->expr->ts.f90_type = sym->ts.u.derived->ts.f90_type;
-	  arg->expr->ts.kind = sym->ts.u.derived->ts.kind;
-	  gfc_conv_expr_reference (se, arg->expr);
-      
-	  return 0;
-	}
-      else if ((sym->intmod_sym_id == ISOCBINDING_F_POINTER
-	         && arg->next->expr->rank == 0)
-	       || sym->intmod_sym_id == ISOCBINDING_F_PROCPOINTER)
-	{
-	  /* Convert c_f_pointer if fptr is a scalar
-	     and convert c_f_procpointer.  */
-	  gfc_se cptrse;
-	  gfc_se fptrse;
-
-	  gfc_init_se (&cptrse, NULL);
-	  gfc_conv_expr (&cptrse, arg->expr);
-	  gfc_add_block_to_block (&se->pre, &cptrse.pre);
-	  gfc_add_block_to_block (&se->post, &cptrse.post);
-
-	  gfc_init_se (&fptrse, NULL);
-	  if (sym->intmod_sym_id == ISOCBINDING_F_POINTER
-	      || gfc_is_proc_ptr_comp (arg->next->expr, NULL))
-	    fptrse.want_pointer = 1;
-
-	  gfc_conv_expr (&fptrse, arg->next->expr);
-	  gfc_add_block_to_block (&se->pre, &fptrse.pre);
-	  gfc_add_block_to_block (&se->post, &fptrse.post);
-	  
-	  if (arg->next->expr->symtree->n.sym->attr.proc_pointer
-	      && arg->next->expr->symtree->n.sym->attr.dummy)
-	    fptrse.expr = build_fold_indirect_ref_loc (input_location,
-						       fptrse.expr);
-	  
-	  se->expr = fold_build2 (MODIFY_EXPR, TREE_TYPE (fptrse.expr),
-				  fptrse.expr,
-				  fold_convert (TREE_TYPE (fptrse.expr),
-						cptrse.expr));
-
-	  return 0;
-	}
-      else if (sym->intmod_sym_id == ISOCBINDING_ASSOCIATED)
-        {
-	  gfc_se arg1se;
-	  gfc_se arg2se;
-
-	  /* Build the addr_expr for the first argument.  The argument is
-	     already an *address* so we don't need to set want_pointer in
-	     the gfc_se.  */
-	  gfc_init_se (&arg1se, NULL);
-	  gfc_conv_expr (&arg1se, arg->expr);
-	  gfc_add_block_to_block (&se->pre, &arg1se.pre);
-	  gfc_add_block_to_block (&se->post, &arg1se.post);
-
-	  /* See if we were given two arguments.  */
-	  if (arg->next == NULL)
-	    /* Only given one arg so generate a null and do a
-	       not-equal comparison against the first arg.  */
-	    se->expr = fold_build2 (NE_EXPR, boolean_type_node, arg1se.expr,
-				    fold_convert (TREE_TYPE (arg1se.expr),
-						  null_pointer_node));
-	  else
-	    {
-	      tree eq_expr;
-	      tree not_null_expr;
-	      
-	      /* Given two arguments so build the arg2se from second arg.  */
-	      gfc_init_se (&arg2se, NULL);
-	      gfc_conv_expr (&arg2se, arg->next->expr);
-	      gfc_add_block_to_block (&se->pre, &arg2se.pre);
-	      gfc_add_block_to_block (&se->post, &arg2se.post);
-
-	      /* Generate test to compare that the two args are equal.  */
-	      eq_expr = fold_build2 (EQ_EXPR, boolean_type_node,
-				     arg1se.expr, arg2se.expr);
-	      /* Generate test to ensure that the first arg is not null.  */
-	      not_null_expr = fold_build2 (NE_EXPR, boolean_type_node,
-					   arg1se.expr, null_pointer_node);
-
-	      /* Finally, the generated test must check that both arg1 is not
-		 NULL and that it is equal to the second arg.  */
-	      se->expr = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
-				      not_null_expr, eq_expr);
-	    }
-
-	  return 0;
-	}
-    }
-
   gfc_is_proc_ptr_comp (expr, &comp);
 
   if (se->ss != NULL)

Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER

[Jerry DeLisle]

On 11/18/2009 02:55 PM, Janus Weil wrote:
>>> As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have
>>> any opinion, other than to note that the "normal" intrinsics are
>>> different beasts altogether.
>>
>> Why are they so much different? Regarding the translation, we do
>> pretty much the same for the ISO_C_BINDING intrinsics as we do for
>> some of the others, namely replacing the call by some inline code.
>> E.g. for C_F_PROCPOINTER, we just put in a simple pointer assignment.
>
> Well, ok, I can see that they are handled a bit differently in some ways.
>
> The least thing one could do would be to just separate out the
> ISO_C_BINDING special handling code from gfc_conv_procedure_call, to
> make it less of a monster.
>
> The attachted patch does this by just putting the ISO_C_BINDING stuff
> into a separate routine. And it does so without introducing any
> regressions in the testsuite (i just checked). Should I commit this to
> trunk?
>
> Cheers,
> Janus

OK after some spelling fixes in the comment. A nit, change to:

+      /* TODO -- the following two lines shouldn't be necessary, but if
+	they're removed, a bug is exposed later in the code path.
+	This workaround was thus introduced, but will have to be
+	removed; please see PR 35150 for details about the issue.  */

Jerry

Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER

[Janus Weil]

2009/11/19 Jerry DeLisle <jvdelisle@verizon.net>:
> On 11/18/2009 02:55 PM, Janus Weil wrote:
>>>>
>>>> As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have
>>>> any opinion, other than to note that the "normal" intrinsics are
>>>> different beasts altogether.
>>>
>>> Why are they so much different? Regarding the translation, we do
>>> pretty much the same for the ISO_C_BINDING intrinsics as we do for
>>> some of the others, namely replacing the call by some inline code.
>>> E.g. for C_F_PROCPOINTER, we just put in a simple pointer assignment.
>>
>> Well, ok, I can see that they are handled a bit differently in some ways.
>>
>> The least thing one could do would be to just separate out the
>> ISO_C_BINDING special handling code from gfc_conv_procedure_call, to
>> make it less of a monster.
>>
>> The attachted patch does this by just putting the ISO_C_BINDING stuff
>> into a separate routine. And it does so without introducing any
>> regressions in the testsuite (i just checked). Should I commit this to
>> trunk?
>
> OK after some spelling fixes in the comment. A nit, change to:
>
> +      /* TODO -- the following two lines shouldn't be necessary, but if
> +       they're removed, a bug is exposed later in the code path.
> +       This workaround was thus introduced, but will have to be
> +       removed; please see PR 35150 for details about the issue.  */

Committed as r154327 with the spelling fixes (the comment above is not
mine, I just carried it over from gfc_conv_procedure call).

Cheers,
Janus