Created attachment 30623 [details]
relevant module

Seems to be explicitly permitted by the Fortran 2003 (at least draft) standard?

Section 7.4.2.2
...
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.
...

(although non-intrinsic elemental procedures are not allowed for some reason).

(In reply to Daniel Price from comment #0)
> 
> ../src/kernels.f90:77.13:
> 
>     wfunc => w_wendlandc6
>              1
> Error: Interface mismatch in procedure pointer assignment at (1): Mismatch
> in PURE attribute
> 
> While I can provide a workaround for this by removing the pure attribute, I
> think this is either a bug or a feature that I don't understand, since it
> must be possible to point to pure procedures with a procedure pointer.

This is clearly a feature, not a bug. And yes, it is possible to point to a pure procedure with a procedure pointer. You just have to make sure that the proc-ptr interface is declared to be pure, too.

The reduced test case below shows two examples of how this can be accomplished.


  implicit none

  interface
    pure real function ifc(q)
      real, intent(in) :: q
    end function
  end interface
  
  procedure(real),    pointer :: wfunc1
  procedure(w_cubic), pointer :: wfunc2
  procedure(ifc),     pointer :: wfunc3

  wfunc1 => w_cubic   ! invalid
  wfunc2 => w_cubic   ! valid
  wfunc3 => w_cubic   ! valid
 
contains

  pure real function w_cubic(q2)
    real, intent(in) :: q2
    w_cubic = 0.
  end function

end

Since this is a non-bug, I'm closing it as invalid.

Hi Janus,

I think you should read the part of the standard I quoted again? It clearly specifies that the procedure target may be pure even if the procedure pointer is not (similar to the way that the interface to a PURE procedure may omit the PURE declaration, but not vice versa).

Hi Andrew,

> I think you should read the part of the standard I quoted again? It clearly
> specifies that the procedure target may be pure even if the procedure
> pointer is not

sorry, I did not read your comment before submitting mine. And I think you're right: Indeed it seems to be permitted by F03 (btw the same wording is given in the F08 standard in section 7.2.2.4).

So, correcting my statement in comment 3: All three assignments are supposed to be valid. Also this is a regression in 4.8 (as 4.7 compiles the test case without errror).

Thanks for checking the standard and correcting me. I will take care of fixing this ...

My first suspicion is that the regression was introduced by this commit:

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=195133

which was the fix for PR54286.

The following patch makes the error go away, but (as expected) causes a failure of proc_ptr_result_8.f90 in the testsuite ...


Index: gcc/fortran/expr.c
===================================================================
--- gcc/fortran/expr.c	(revision 201520)
+++ gcc/fortran/expr.c	(working copy)
@@ -3581,14 +3581,6 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
 	  return false;
 	}
 
-      if (!gfc_compare_interfaces (s2, s1, name, 0, 1,
-				   err, sizeof(err), NULL, NULL))
-	{
-	  gfc_error ("Interface mismatch in procedure pointer assignment "
-		     "at %L: %s", &rvalue->where, err);
-	  return false;
-	}
-
       return true;
     }

(In reply to janus from comment #7)
> The following patch makes the error go away, but (as expected) causes a
> failure of proc_ptr_result_8.f90 in the testsuite ...

... which can be made up for with this hunk:


Index: gcc/fortran/interface.c
===================================================================
--- gcc/fortran/interface.c	(revision 201520)
+++ gcc/fortran/interface.c	(working copy)
@@ -1416,7 +1416,8 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol
       if (s1->attr.function && s2->attr.function)
 	{
 	  /* If both are functions, check result characteristics.  */
-	  if (!check_result_characteristics (s1, s2, errmsg, err_len))
+	  if (!check_result_characteristics (s1, s2, errmsg, err_len)
+	      || !check_result_characteristics (s2, s1, errmsg, err_len))
 	    return 0;
 	}

I have just verified that the combined patches of comment 7 and 8 regtest cleanly.

(In reply to janus from comment #7)
> The following patch makes the error go away, but (as expected) causes a
> failure of proc_ptr_result_8.f90 in the testsuite ...
> -      if (!gfc_compare_interfaces (s2, s1, name, 0, 1,
> -				   err, sizeof(err), NULL, NULL))
> -	{
> -	  gfc_error ("Interface mismatch in procedure pointer assignment "
> -		     "at %L: %s", &rvalue->where, err);
> -	  return false;
> -	}


Doesn't that remove too much? I had expected some special case for PURE, while checking otherwise that the interface matches. (Except for the case where the proc-pointer only has an implicit interface like for "procedure(real)", unless some characteristic of the RHS requires an explicit interface.)

* * *

Side note: The following compiles but should give an error as the interface doesn't match. (If one swaps the pure, it does and should compile warning free.)

subroutine foo()
end

interface
  pure subroutine foo()
  end subroutine foo
end interface
call foo()
end

I just saw that Janus has already posted a patch: http://gcc.gnu.org/ml/fortran/2013-08/msg00026.html , which is probably sufficient for 4.8. But for 4.9 [at least as follow up], see my previous remarks (comment 10).

(In reply to Tobias Burnus from comment #10)
> (In reply to janus from comment #7)
> > The following patch makes the error go away, but (as expected) causes a
> > failure of proc_ptr_result_8.f90 in the testsuite ...
> > -      if (!gfc_compare_interfaces (s2, s1, name, 0, 1,
> > -				   err, sizeof(err), NULL, NULL))
> > -	{
> > -	  gfc_error ("Interface mismatch in procedure pointer assignment "
> > -		     "at %L: %s", &rvalue->where, err);
> > -	  return false;
> > -	}
> 
> 
> Doesn't that remove too much? I had expected some special case for PURE,
> while checking otherwise that the interface matches.

No, I don't think it removes too much. It seems that the other parts of 'gfc_compare_interfaces' are already symmetrized appropriately, expect for the check on the result characteristics.


> Side note: The following compiles but should give an error as the interface
> doesn't match. (If one swaps the pure, it does and should compile warning
> free.)
> 
> subroutine foo()
> end
> 
> interface
>   pure subroutine foo()
>   end subroutine foo
> end interface
> call foo()
> end

Well, it does give the expected warning with the patch:

  pure subroutine foo()
                     1
Warning: Interface mismatch in global procedure 'foo' at (1): Mismatch in PURE attribute

(In reply to janus from comment #12)
> (In reply to Tobias Burnus from comment #10)
> > (In reply to janus from comment #7)
> > > The following patch makes the error go away, but (as expected) causes a
> > > failure of proc_ptr_result_8.f90 in the testsuite ...
> > > -      if (!gfc_compare_interfaces (s2, s1, name, 0, 1,
> > > -				   err, sizeof(err), NULL, NULL))
> > > -	{
> > > -	  gfc_error ("Interface mismatch in procedure pointer assignment "
> > > -		     "at %L: %s", &rvalue->where, err);
> > > -	  return false;
> > > -	}
> > 
> > 
> > Doesn't that remove too much? I had expected some special case for PURE,
> > while checking otherwise that the interface matches.
> 
> No, I don't think it removes too much. It seems that the other parts of
> 'gfc_compare_interfaces' are already symmetrized appropriately, expect for
> the check on the result characteristics.

Here is another recent example where more symmetrization was done (this time in check_dummy_characteristics):

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199375

In case we need more symmetrization, it should be done 'locally'. Duplicate calls of gfc_compare_interfaces to symmetrize it are clearly wrong, as the case with PURE shows.

Janus' submitted patch: http://gcc.gnu.org/ml/fortran/2013-08/msg00026.html

Looks great and fixes also comment 10's test case.

 * * *

I tried to test for the "intrinsic elemental" of comment 2's standard quote. That works without "elemental" in the INTERFACE but not with. However, the standard states for "acos": "Class. Elemental function." Nonetheless, gfortran prints:

  Error: Interface mismatch in procedure pointer assignment at (1):
         Mismatch in PURE attribute"

for

intrinsic acos
interface
  elemental real function oo(x) ! Works (and should work) without "elemental"
    real, intent(in) :: x
  end function
end interface
procedure(oo),pointer :: bar
bar => acos
end

Author: janus
Date: Fri Sep 20 07:44:05 2013
New Revision: 202766

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

	PR fortran/58099
	* expr.c (gfc_check_pointer_assign): Remove second call to
	'gfc_compare_interfaces' with swapped arguments.
	* interface.c (gfc_compare_interfaces): Symmetrize the call to
	'check_result_characteristics' by calling it with swapped arguments.

2013-09-20  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/58099
	* gfortran.dg/proc_ptr_43.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_43.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/interface.c
    trunk/gcc/testsuite/ChangeLog

(In reply to janus from comment #15)
> Author: janus
> Date: Fri Sep 20 07:44:05 2013
> New Revision: 202766

This commit fixes the original regression of comment 0 on trunk (backport to 4.8 pending).

TODO: Fix also the issue with PURE/ELEMENTAL reported in comment 14.

(In reply to janus from comment #16)
> TODO: Fix also the issue with PURE/ELEMENTAL reported in comment 14.

Here is a small patch which does it:

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 202765)
+++ gcc/fortran/resolve.c	(working copy)
@@ -1679,6 +1679,11 @@ gfc_resolve_intrinsic (gfc_symbol *sym, locus *loc
 
   gfc_copy_formal_args_intr (sym, isym);
 
+  if (isym->pure && !gfc_add_pure (&sym->attr, &sym->declared_at))
+    return false;
+  if (isym->elemental && !gfc_add_elemental (&sym->attr, &sym->declared_at))
+    return false;
+
   /* Check it is actually available in the standard settings.  */
   if (!gfc_check_intrinsic_standard (isym, &symstd, false, sym->declared_at))
     {


The PURE and ELEMENTAL properties of the intrinsic procedures were just not properly propagated during symbol resolution.

(In reply to janus from comment #17)
> (In reply to janus from comment #16)
> > TODO: Fix also the issue with PURE/ELEMENTAL reported in comment 14.
> 
> Here is a small patch which does it:

This yields a rather large number of failures in the testsuite, due to errors of the type:

  USE ISO_C_BINDING
      1
Error: Cannot change attributes of USE-associated symbol at (1)


This is avoided by the following improved patch (which just 'silently' sets the attributes):

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(revision 202765)
+++ gcc/fortran/resolve.c	(working copy)
@@ -1679,6 +1679,9 @@ gfc_resolve_intrinsic (gfc_symbol *sym, locus *loc
 
   gfc_copy_formal_args_intr (sym, isym);
 
+  sym->attr.pure = isym->pure;
+  sym->attr.elemental = isym->elemental;
+
   /* Check it is actually available in the standard settings.  */
   if (!gfc_check_intrinsic_standard (isym, &symstd, false, sym->declared_at))
     {

(In reply to janus from comment #18)
> This is avoided by the following improved patch (which just 'silently' sets
> the attributes):

That version still yields a good number of testsuite failures, but it seems like most of them are due to invalid code that was not detected previously:

FAIL: gfortran.dg/proc_decl_9.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_1.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_11.f90  -O  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_12.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_15.f90  -O  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_6.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_common_1.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_result_1.f90  -O0  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_result_2.f90  -O  (test for excess errors)
FAIL: gfortran.dg/proc_ptr_result_8.f90  -O  (test for excess errors)
FAIL: gfortran.dg/sizeof_proc.f90  -O  (test for excess errors)

So for now I'm assuming the patch is fine. I will go through the above list in detail and update the test cases accordingly.

(In reply to janus from comment #19)
> FAIL: gfortran.dg/proc_ptr_1.f90  -O0  (test for excess errors)

Here one gets:

  ptr4 => cos
  1
Error: Explicit interface required for '' at (1): elemental procedure

The error message as such is correct, but: The name of 'ptr4' is not printed!

GCC 4.8.2 has been released.

(In reply to janus from comment #19)
> (In reply to janus from comment #18)
> That version still yields a good number of testsuite failures, but it seems
> like most of them are due to invalid code that was not detected previously:

Well, sizeof_proc.f90 looks like a bug in the checking code:

 procedure(real), pointer :: pp
 pp => sin
! Error: Explicit interface required for '' at (1): elemental procedure


The quote in comment 2 has: "If proc-pointer-object has an explicit interface…" which is not fulfilled as "pp" has an implicit interface.

There is in addition the following constraint, but sin is an intrinsic:
"C730 (R740) The proc-target shall not be a nonintrinsic elemental procedure."


The issue with the name should be solved by setting a name var in gfc_check_pointer_assign not only for s2 but also s1 - otherwise, s1 points to the interface, which won't work.

Author: janus
Date: Sat Nov 16 23:13:31 2013
New Revision: 204908

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

	Backport from mainline
	2013-09-20  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/58099
	* expr.c (gfc_check_pointer_assign): Remove second call to
	'gfc_compare_interfaces' with swapped arguments.
	* interface.c (gfc_compare_interfaces): Symmetrize the call to
	'check_result_characteristics' by calling it with swapped arguments.


2013-11-16  Janus Weil  <janus@gcc.gnu.org>

	Backport from mainline
	2013-09-20  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/58099
	* gfortran.dg/proc_ptr_43.f90: New.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/proc_ptr_43.f90
      - copied unchanged from r202766, trunk/gcc/testsuite/gfortran.dg/proc_ptr_43.f90
Modified:
    branches/gcc-4_8-branch/   (props changed)
    branches/gcc-4_8-branch/gcc/fortran/ChangeLog
    branches/gcc-4_8-branch/gcc/fortran/expr.c
    branches/gcc-4_8-branch/gcc/fortran/interface.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-4_8-branch/
            ('svn:mergeinfo' modified)

The original regression has been fixed on trunk and 4.8 with r202766 and r204908, respectively.

Still to do: Fix the test case of comment 14, cf. also comment 17 - 20 as well as comment 22.

(In reply to Tobias Burnus from comment #22)
> (In reply to janus from comment #19)
> > (In reply to janus from comment #18)
> > That version still yields a good number of testsuite failures, but it seems
> > like most of them are due to invalid code that was not detected previously:
> 
> Well, sizeof_proc.f90 looks like a bug in the checking code:
> 
>  procedure(real), pointer :: pp
>  pp => sin
> ! Error: Explicit interface required for '' at (1): elemental procedure

There might be a bug here, but I don't quite follow your argument (see below).


> The quote in comment 2 has: "If proc-pointer-object has an explicit
> interface…" which is not fulfilled as "pp" has an implicit interface.

Agreed. The quote continues "... its characteristics shall be the same as proc-target except ...". The error is not about the characteristics being different, but about the target being elemental at all. Everything is fine so far.


> There is in addition the following constraint, but sin is an intrinsic:
> "C730 (R740) The proc-target shall not be a nonintrinsic elemental
> procedure."

Yes. As you say, this is not applicable here (and is again not what the error is about). Still everything fine.


The relevant quote for the above error message is F08:12.4.2.2, which says:

" A procedure other than a statement function shall have an explicit interface if it is referenced and ... (4) the procedure is elemental, or ..."

In our case it applies to the proc-pointer 'pp', which itself is not elemental, but (validly) points to the elemental intrinsic 'sin'.


Therefore I would say the logic in gfc_check_pointer_assign is wrong after all:

      if (s1->attr.if_source == IFSRC_UNKNOWN
	  && gfc_explicit_interface_required (s2, err, sizeof(err)))
	{
	  gfc_error ("Explicit interface required for '%s' at %L: %s",
		     name1, &lvalue->where, err);

I guess we should not require an explicit interface for the pointer, if the target is elemental. Right?

(In reply to janus from comment #25)
> The relevant quote for the above error message is F08:12.4.2.2, which says:

Good pointer, though I am not sure whether it is relevant.

Another one is "12.4.3.6 Procedure declaration statement" which is relevant for the interface declaration part of the proc-pointer.

 * * *

With some digging I found 09-166 - but according to the m188 notes no further action is done.

And a bit less fitting but with passed J3/WG5, one has: 09-171r1, which got revised as 09-217 and passed the ballot as Interpretation Request F03-0130. See: http://j3-fortran.org/doc/year/09/09-217.txt and http://j3-fortran.org/doc/year/10/10-006T5r1.txt.

From F03-0130:

Q: "When one of these procedures [i.e. the specific intrinsic procedures listed in 13.6 and not marked with a bullet] is associated with a dummy procedure or procedure pointer, does it still have the elemental property?"

A: "The specific intrinsic procedure itself retains the elemental property (so a reference using its own name can be elemental), but the dummy procedure or procedure pointer associated with it is not elemental and so cannot be used to reference the specific intrinsic procedure elementally."

 * * *

As far as I can see, it seems to be valid to have:
  intrinsic :: sin
  procedure(real), pointer :: pp1 => sin
  procedure(sin), pointer :: pp2 => sin ! valid per C1216

  interface
    pure function sin_like(x)
      real, intent(in) :: x
    end function sin_like
  end interface
  procedure(sin_like), pointer :: pp3 => sin

But in all cases, the proc-pointer is not elemental. It doesn't seem to be valid to have:

  interface
    pure ELEMENTAL function sin_like(x)
      real, intent(in) :: x
    end function sin_like
  end interface
  procedure(sin_like), pointer :: pp4 => sin

But is is valid to have a non-proc-pointer PROCEDURE statement like:
  procedure(sin_like) :: external_sin_like_function

For the latter two, the following applies:
"C1218 (R1211) If a proc-interface describes an elemental procedure, each procedure-entity-name shall specify an external procedure."

[Side note: We should also check that dummy arguments are correctly handled.]

(In reply to Tobias Burnus from comment #26)
> A: "The specific intrinsic procedure itself retains the elemental property
> (so a reference using its own name can be elemental), but the dummy
> procedure or procedure pointer associated with it is not elemental and so
> cannot be used to reference the specific intrinsic procedure elementally."

Thus, the following code is invalid:

interface
  elemental real function x(y) ! Valid external procedure
     real, intent(in) :: y
  end function x
end interface
   ! pointer :: x  ! < comment aside: this proc-ptr would violate C1218
intrinsic :: sin
call foo(sin)
contains
  subroutine foo(z)
    procedure(x) :: z      ! INVALID per C1218
!   procedure(sin) :: z    ! Valid - but not elemental ...
    print *, z([1.,2.,3.]) ! ... hence this invalid too for "procedure(sin)::z"
  end subroutine foo
end


See also:

"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)."
[The parenthesis is a consequence of C1218, see comment 26 for the quote.]

Thus:
* I think we need a check for elemental as dummy argument and reject it
* For the patch (comment 18), I wonder whether whether one should leave out the "elemental" assignment and just do the "pure" assignment.

Author: burnus
Date: Sun Dec  8 21:34:18 2013
New Revision: 205791

URL: http://gcc.gnu.org/viewcvs?rev=205791&root=gcc&view=rev
Log:
2013-12-08  Tobias Burnus  <burnus@net-b.de>
            Janus Weil  <janus@gcc.gnu.org>

        PR fortran/58099
        PR fortran/58676
        PR fortran/41724
        * resolve.c (gfc_resolve_intrinsic): Set elemental/pure.
        (resolve_fl_procedure): Reject pure dummy procedures/procedure
        pointers.
        (gfc_explicit_interface_required): Don't require a
        match of ELEMENTAL for intrinsics.

2013-12-08  Tobias Burnus  <burnus@net-b.de>

        PR fortran/58099
        PR fortran/58676
        PR fortran/41724
        * gfortran.dg/elemental_subroutine_8.f90: New.
        * gfortran.dg/proc_decl_9.f90: Add ELEMENTAL to make valid.
        * gfortran.dg/proc_ptr_11.f90: Ditto.
        * gfortran.dg/proc_ptr_result_8.f90: Ditto.
        * gfortran.dg/proc_ptr_32.f90: Update dg-error.
        * gfortran.dg/proc_ptr_33.f90: Ditto.
        * gfortran.dg/proc_ptr_result_1.f90: Add abstract interface
        which is not elemental.
        * gfortran.dg/proc_ptr_result_7.f90: Ditto.


Added:
    trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_8.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/proc_decl_9.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_32.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_33.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_1.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_7.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_8.f90

I think all issues of the PR are FIXED.

The original problem (plus comment 10) seems to be fixed by the commits mentioned in comment 15 (4.9) and - backported to GCC 4.8 - by comment 23.


A follow-up issue has been fixed in comment 28.

Thus, I close now the PR. Thanks for the bug report Daniel, for the standard quotes Andrew and for the first patch Janus!

thanks very much for the speedy and professional response Tobias et al!

Daniel

On 9 Dec 2013, at 8:42 am, burnus at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099
> 
> Tobias Burnus <burnus at gcc dot gnu.org> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|ASSIGNED                    |RESOLVED
>         Resolution|---                         |FIXED
> 
> --- Comment #29 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> I think all issues of the PR are FIXED.
> 
> The original problem (plus comment 10) seems to be fixed by the commits
> mentioned in comment 15 (4.9) and - backported to GCC 4.8 - by comment 23.
> 
> 
> A follow-up issue has been fixed in comment 28.
> 
> Thus, I close now the PR. Thanks for the bug report Daniel, for the standard
> quotes Andrew and for the first patch Janus!
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

Author: burnus
Date: Mon Dec  9 23:17:06 2013
New Revision: 205838

URL: http://gcc.gnu.org/viewcvs?rev=205838&root=gcc&view=rev
Log:
2013-12-10  Tobias Burnus  <burnus@net-b.de>

        PR fortran/59428
        PR fortran/58099
        PR fortran/58676
        PR fortran/41724
        * gfortran.dg/proc_ptr_result_4.f90: Fix proc-ptr interface.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_4.f90