Beginning with the OpenMP API Version 2.5, this case should fail at compile-time. The gfortran compiler does not reject this case, but gets a segmentation fault at run-time. The OpenMP API Version 3.0 (May 2008) lists the following restriction to a private clause on p 91. lines 29-30: " * Variables that appear in ... expressions for statement function definitions, may not appear in a private clause." Test case: > cat ISU3136.f90 ! derived from OpenMP test omp1/F2_6_2_1_2a.f90 ! According to OpenMP API Ver 2.5 May 2005 p. 75 lines 19/20 ! this is a negative test that should fail at compile-time. use omp_lib implicit none integer, parameter :: NT = 4 integer :: nThreads(NT) integer :: a, st_func, i st_func() = a + 1 !$ call omp_set_dynamic(.false.) !$ call omp_set_num_threads(NT) !$omp parallel private(a) a = omp_get_thread_num() !$omp barrier nThreads(omp_get_thread_num()+1) = st_func() !$omp end parallel do i = 1, NT if(nThreads(i) /= i) then print*, 'FAIL: non-private copy is used in a statement function.' endif enddo END > ftn -o x -fopenmp ISU3136.f90 > aprun -n 1 ./x Application 1190869 exit signals: Segmentation fault Application 1190869 resources: utime 0, stime 0 Expected output (using the Cray compiler) with a compile-time message: > module swap PrgEnv-gnu PrgEnv-cray > ftn -o x -h omp ISU3136.f90 !$omp parallel private(a) ^ ftn-1760 crayftn: ERROR $MAIN, File = ISU3136.f90, Line = 14, Column = 24 "A" is referenced in a statement function expression, so it must not be specified in the PRIVATE, FIRSTPRIVATE or LASTPRIVATE clause.
I certainly can't reproduce any kind of segfault with this. And, it is unclear to me whether this restriction (why it is there at all, doesn't make much sense) is meant just for statement functions referenced within the omp region, or any. Say is: integer :: a, st_func st_func () = a !$omp parallel private (a) a = 1 !$omp end parallel end also supposed to be invalid?
The text at [75:19-20] of the OpenMP 2.5 standard, May 2008, says: "Variables that appear in namelist statements, in variable format expressions, and in Fortran expressions for statement function definitions, may not appear in a private clause." So the example in Comment #1 looks invalid.
(In reply to comment #1) > I certainly can't reproduce any kind of segfault with this. It could be that it segfaults for Bill because 'ftn' adds -static to the compiler options, but doesn't link libpthread with '-Wl,--whole-archive -lpthread -Wl,--no-whole-archive' (see PR39176). Certainly, this happened in the past on the XT5. It is something Bill could check on the Cray :-)
(In reply to comment #1) > I certainly can't reproduce any kind of segfault with this. Neither can I. Regarding both examples (comment 0 and comment 1), ifort 11.1 happily accepts both. I am not sure whether it is the correct interpretation according the standard, but http://publib.boulder.ibm.com/infocenter/lnxpcomp/v9v111/topic/com.ibm.xlf111.linux.doc/xlfopg/smpdirclauses.htm has: "The following example demonstrates the proper use of a PRIVATE variable that is used to define a statement function. A commented line shows the invalid use. Since J appears in a statement function, the statement function cannot be referenced within the parallel construct for which J is PRIVATE. INTEGER :: ARR(10), J = 17 ISTFNC() = J !$OMP PARALLEL DO PRIVATE(J) DO I = 1, 10 J=I ARR(I) = J ! ARR(I) = ISTFNC() **ERROR** A reference to ISTFNC would ! make the PRIVATE(J) clause ! invalid. END DO PRINT *, ARR END " However, I somehow read the standard differently such that already the "PRIVATE(J)" is invalid.
I tried 4.4.2 and do not any longer see the segfault on the Cray XT system. I suspect this was fixed by addressing the problem noted in Comment #3. The original problem of not issuing the error message at compile time remains. This (correct) comment in Comment #5: --- However, I somehow read the standard differently such that already the "PRIVATE(J)" is invalid. --- focuses on the actual issue.
(In reply to comment #5) > I tried 4.4.2 and do not any longer see the segfault on the Cray XT system. This PR can thus be closed?
The original problem reported in the Description concerned a missing error message. So, fixing the segfault (while an excellent situation) does not address the original issue. My 2 cents is this is not ready to close yet.
I am out of the office until Monday, January 3, 2011. Send technical questions to spslang@cray.com.
Relate to/duplicate of pr38724?
> Relate to/duplicate of pr38724? Marked as duplicate of pr38724. *** This bug has been marked as a duplicate of bug 38724 ***
With 10.2.0 there is still no error message for the invalid use of A in a private() clause of the OpenMP directive.