Bug 45366 - Problem with procedure pointer dummy in PURE function
Summary: Problem with procedure pointer dummy in PURE function
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2010-08-21 12:29 UTC by mrestelli
Modified: 2010-08-23 12:29 UTC (History)
2 users (show)

See Also:
Host: AMD Turion(tm) 64 Mobile Technology ML-32 AuthenticAMD GNU/Linux
Target:
Build: GNU Fortran (GCC) 4.6.0 20100821 (experimental)
Known to work:
Known to fail: 4.4.3 4.5.2 4.6.0
Last reconfirmed: 2010-08-22 10:50:10


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mrestelli 2010-08-21 12:29:54 UTC
Hi all,
   gfortran refuses the attached code as

pure function i_g(x,p) result(y)
                     1
Error: Dummy procedure 'p' of PURE procedure at (1) must also be PURE

Notice however that i_f is an abstract interface to a PURE function.
(As a comment, ifort accepts the code.)


module m1
 implicit none
 abstract interface
  pure function i_f(x) result(y)
   real, intent(in) :: x
   real :: y
  end function i_f
 end interface
end module m1

module m2
 use m1, only: i_f
 implicit none
contains
 pure function i_g(x,p) result(y)
  real, intent(in) :: x
  procedure(i_f), pointer, intent(in) :: p
  real :: y
   y = p(x)
 end function i_g
end module m2
Comment 1 janus 2010-08-22 10:50:10 UTC
Confirmed. Thanks for reporting.
Comment 2 Tobias Burnus 2010-08-22 11:02:23 UTC
Note: The ABSTRACT, the INTERFACE (vs. host-association), and the use-association of i_f do not seem to play a role.

In particular for p:
  sym->attr.pure == 0
  sym->attr.proc_pointer == 1
  sym->ts.interface->attr.pure == 1

The problems seems to be that resolve_symbol is called later than the resolve_formal_arglist check for pureness, i.e. one first checks whether "p" is pure before one copies the attr.pure from ts.interface->attr.pure - which explains the failure.

I leave the fixing to Janus.
Comment 3 janus 2010-08-22 11:10:04 UTC
(In reply to comment #2)
> The problems seems to be that resolve_symbol is called later than the
> resolve_formal_arglist check for pureness, i.e. one first checks whether "p" is
> pure before one copies the attr.pure from ts.interface->attr.pure - which
> explains the failure.

Exactly. I'm regtesting a patch right now.
Comment 4 janus 2010-08-23 12:26:58 UTC
Subject: Bug 45366

Author: janus
Date: Mon Aug 23 12:26:42 2010
New Revision: 163468

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163468
Log:
2010-08-23  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/45366
	* resolve.c (resolve_procedure_interface): New function split off from
	'resolve_symbol'.
	(resolve_formal_arglist): Call it here ...
	(resolve_symbol): ... and here.


2010-08-23  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/45366
	* gfortran.dg/proc_ptr_29.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_29.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

Comment 5 janus 2010-08-23 12:29:09 UTC
Fixed with r163468. Closing.