Summary: | [F03] OpenMP default(none) and procedure pointers | ||
---|---|---|---|
Product: | gcc | Reporter: | mrestelli <mrestelli> |
Component: | fortran | Assignee: | janus |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jakub, janus |
Priority: | P3 | Keywords: | openmp, rejects-valid |
Version: | 4.6.0 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2013-06-23 00:00:00 |
Description
mrestelli
2010-11-02 16:55:51 UTC
Still present at revision 200321. 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); (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? (In reply to janus from comment #2) > Here is a simple patch to accept version A: ... which regtests cleanly! (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 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 (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! |