Bug 46271 - [F03] OpenMP default(none) and procedure pointers
Summary: [F03] OpenMP default(none) and procedure pointers
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: openmp, rejects-valid
Depends on:
Blocks:
 
Reported: 2010-11-02 16:55 UTC by mrestelli
Modified: 2013-08-19 09:18 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-23 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mrestelli 2010-11-02 16:55:51 UTC
gfortran rejects the attached code both in version A and B. A similar
problem is discussed in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036

but, to my understanding, this only covers the case of a procedure
pointer associated with a function, not the subroutine case.


gfortran --version
GNU Fortran (GCC) 4.6.0 20101019 (experimental)


With version A:
gfortran -fopenmp omp_test.f90 -o omp_test
omp_test.f90:22.59:

  !$omp   private(i) shared(s,pf) default(none) ! version A
                                                           1
Error: Object 'pf' is not a variable at (1)

With version B:
gfortran -fopenmp omp_test.f90 -o omp_test
omp_test.f90: In function ‘test’:
omp_test.f90:25:0: error: ‘pf’ not specified in enclosing parallel
omp_test.f90:23:0: error: enclosing parallel



module ma
 implicit none
contains
 pure subroutine f(x,y)
  real, intent(in) :: x
  real, intent(out) :: y
   y = sin(x)*cos(x)
 end subroutine f
end module ma

program test
 use ma, only: f
 implicit none
 integer :: i
 real :: s(1000)
 procedure(f), pointer :: pf
 
  pf => f

  !$omp parallel do schedule(static) &
  ! !$omp   private(i) shared(s,pf) default(none) ! version A
  !$omp   private(i) shared(s) default(none) ! version B
  do i=1,1000
    call pf(real(i),s(i))
  enddo
  !$omp end parallel do

  write(*,*) 'Sum ',sum(s)
end program test
Comment 1 Dominique d'Humieres 2013-06-23 14:08:40 UTC
Still present at revision 200321.
Comment 2 janus 2013-08-12 13:55:25 UTC
Here is a simple patch to accept version A:


Index: gcc/fortran/openmp.c
===================================================================
--- gcc/fortran/openmp.c	(revision 201653)
+++ gcc/fortran/openmp.c	(working copy)
@@ -847,7 +847,7 @@ resolve_omp_clauses (gfc_code *code)
     for (n = omp_clauses->lists[list]; n; n = n->next)
       {
 	n->sym->mark = 0;
-	if (n->sym->attr.flavor == FL_VARIABLE)
+	if (n->sym->attr.flavor == FL_VARIABLE || n->sym->attr.proc_pointer)
 	  continue;
 	if (n->sym->attr.flavor == FL_PROCEDURE
 	    && n->sym->result == n->sym
@@ -876,8 +876,6 @@ resolve_omp_clauses (gfc_code *code)
 		if (el)
 		  continue;
 	      }
-	    if (n->sym->attr.proc_pointer)
-	      continue;
 	  }
 	gfc_error ("Object '%s' is not a variable at %L", n->sym->name,
 		   &code->loc);
Comment 3 janus 2013-08-12 13:59:08 UTC
(In reply to mrestelli from comment #0)
> With version B:
> gfortran -fopenmp omp_test.f90 -o omp_test
> omp_test.f90: In function ‘test’:
> omp_test.f90:25:0: error: ‘pf’ not specified in enclosing parallel
> omp_test.f90:23:0: error: enclosing parallel

What is actually the problem here? That error message looks correct to me, doesn't it?
Comment 4 janus 2013-08-12 15:45:30 UTC
(In reply to janus from comment #2)
> Here is a simple patch to accept version A:

... which regtests cleanly!
Comment 5 mrestelli 2013-08-12 16:29:12 UTC
(In reply to janus from comment #3)
> (In reply to mrestelli from comment #0)
> > With version B:
> > gfortran -fopenmp omp_test.f90 -o omp_test
> > omp_test.f90: In function ‘test’:
> > omp_test.f90:25:0: error: ‘pf’ not specified in enclosing parallel
> > omp_test.f90:23:0: error: enclosing parallel
> 
> What is actually the problem here? That error message looks correct to me,
> doesn't it?

Janus, you are probably right that version B should not compile. I
guess when I posted the bug report I was not sure which was the
correct version according to the OpenMP specifications, since fp is a
variable (requiring an OpenMP attribute), but it behaves like a
subroutine (so, no OpenMP attribute). Clearly however at least one of
the two versions should work, hence my pointing out that both
alternatives do not work. Well, at least this is my recollection,
since it was quite a while ago.

As a note, I mention that ifort (version 13.1) accepts both versions,
but maybe this is an issue with ifort itself.

Regards,
   Marco Restelli
Comment 6 janus 2013-08-12 17:08:14 UTC
Hi Marco,

> Janus, you are probably right that version B should not compile. I
> guess when I posted the bug report I was not sure which was the
> correct version according to the OpenMP specifications, since fp is a
> variable (requiring an OpenMP attribute), but it behaves like a
> subroutine (so, no OpenMP attribute).

well, since a procedure pointer can be assigned and change its value, I would say it counts as a variable and one should make up one's mind whether it is supposed to be shared or private in an OpenMP loop (as for any other variable, this can clearly make a difference). Hence my interpretation that the error message is correct.

However, I should note that I'm not much of an OpenMP expert and haven't checked whether the OpenMP specifications makes any definitive statement about this. It's merely my 'gut feeling'.


> As a note, I mention that ifort (version 13.1) accepts both versions,
> but maybe this is an issue with ifort itself.

ifort is not exactly known for it's strictness on invalid programs, and of course it may have bugs. I don't know if this is allowed on purpose or if the missing error is an oversight.

If ifort accepts the program, it would be interesting whether it treats the procptr as private or shared with default(none), and whether this behavior is documented somewhere (either in the OpenMP spec or the ifort docs).

Some people claim that documentation is the only thing that distinguishes a feature from a bug ;)

Cheers,
Janus
Comment 7 janus 2013-08-19 09:18:11 UTC
(In reply to janus from comment #2)
> Here is a simple patch to accept version A:

... which has been committed to 4.9 trunk:


Author: janus
Date: Mon Aug 19 09:03:20 2013
New Revision: 201835

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

	PR fortran/46271
	* openmp.c (resolve_omp_clauses): Bugfix for procedure pointers.


2013-08-19  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46271
	* gfortran.dg/gomp/proc_ptr_1.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/gomp/proc_ptr_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/openmp.c
    trunk/gcc/testsuite/ChangeLog



I think the rejection of version B is ok (see above discussion), therefore I'm closing this PR. Thanks for the report!