The GNU compiler is asking that when a default(none) clause is present on the OMP PARALLEL DO, and a chunk-size expression (in this case just the variable fsize) appears in a schedule clause, that the variable must appear in a shared or private clause. Other compilers (PGI, Pathscale) do not require that this be done. I cannot find a justification for requiring that fsize be listed in a private or shared clause. It is referenced before the construct begins execution, but not within the construct itself. Admittedly, the OpenMP 2.5 spec is a bit weak on scoping rules in this case, but the text at page 63 lines 25-28 hints to me that a variable that appears in a schedule clause is not automatically a reference. The text on page 36 lines 1-19 says that IF the variable is declared private then the value used is not the private copy but rather the value of the version external to the construct. Again this suggests that the variable in the schedule clause is outside the scope of the construct. > gfortran -c -fopenmp test.f90 test.f90: In function 'MAIN__': test.f90:16: error: 'fsize' not specified in enclosing parallel test.f90:16: error: enclosing parallel > cat test.f90 program OMP_program ! derived from ISU's RTED_OpenMP/FORTRAN/SECTION_C/F_C_3_2_a.f90 ! RTED_OpenMP/FORTRAN/SECTION_C/F_C_3_2_d.f90 integer, parameter :: nt=4 double precision :: s,tmp double precision :: ARR(100) integer :: fsize,i call omp_set_num_threads(nt) s = 0.d0 arr = 1.0d0 tmp = 4.d0*atan(1.d0) fsize = int(sin(-0.25*tmp)*10.0) write(*,*) 'tmp, fsize',tmp, fsize !$omp parallel do default(none) shared(arr) private(i) reduction(+:s) schedule(static,fsize) do i=1,100 s = s + arr(i) end do !$omp end parallel do print *,'s =', s end program OMP_program
Jakub, do you agree that this is a bug or is this no bug?
Pedantically this is not a bug. If an omp sentinel doesn't have the desired form, it should be handled as a normal comment. As the preceeding line doesn't end with &, then !$omp& is not a valid omp sentinel (as !$omp needs to be followed by a space) and thus it is the same as say ! $ omp & something That said, perhaps we could issue some diagnostics, because it is likely a user error rather than intent.
> Pedantically this is not a bug. If an omp sentinel doesn't have the desired > form, it should be handled as a normal comment. I think your comment is with regards to PR 33445 and not regarding this PR (PR33439).
I think the standard is very vague here. First consider: !$omp parallel default(none) call something !$omp do schedule(static, chunksize) do i=1,100 call somethingelse done !$omp end do !$omp end parallel Do you agree that this must issue an error? Here page 36 only says that if there was say !$omp do schedule(static, chunksize) private(chunksize), then schedule would use the outer chunksize, while inside of the loop would be a different, privatized, variable. I can't see how chunksize wouldn't count here as a reference of that variable inside of the parallel. Now, consider: !$omp parallel default(none) !$omp do schedule(static, chunksize) do i=1,100 call somethingelse done !$omp end do !$omp end parallel I believe this falls to the same category as the previous one. Now, for the combined parallel it is very unclear, but doesn't section 2.6 say they have the same semantics as the above?
http://openmp.org/pipermail/omp/2007/001067.html
Subject: Bug 33439 Author: jakub Date: Fri Sep 21 11:17:13 2007 New Revision: 128649 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128649 Log: PR fortran/33439 * gfortran.dg/gomp/pr33439.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr33439.f90 Modified: trunk/gcc/testsuite/ChangeLog
*** Bug 33718 has been marked as a duplicate of this bug. ***
Here is how other compilers process this code: PGI: $ pgf90 -mp test.f90 $ ./a.out Warning: omp_set_num_threads (4) greater than available cpus (2) tmp, fsize 3.141592653589793 -7 s = 0.000000000000000 $ pgf90 test.f90 $ ./a.out tmp, fsize 3.141592653589793 -7 s = 100.0000000000000 $ Intel: $ ifort -openmp test.f90 $ ./a.out tmp, fsize 3.14159265358979 -7 s = 100.000000000000 $ ifort test.f90 /tmp/pbs.1871075.sdb/ifortE1EQWX.o: In function `MAIN__': test.f90:(.text+0x3e): undefined reference to `omp_set_num_threads_' $ Cray: $ ftn -target=native -Oomp test.f90 /opt/cray/xt-asyncpe/3.3/bin/ftn: INFO: native target is being used $ ./a.out tmp, fsize 3.1415926535897931, -7 s = 0. $ ftn -target=native -Onoomp test.f90 /opt/cray/xt-asyncpe/3.3/bin/ftn: INFO: native target is being used $ ./a.out tmp, fsize 3.1415926535897931, -7 s = 100. $ I would say that none of the above are desired behavior, but rather a runtime error message should be printed out.
The OpenMP spec does require (requirement is on the user): "chunk_size must be a loop invariant integer expression with a positive value", so detection of a chunk size of -7 at run time would be a user-friendly thing to do.