http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564
--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-10 09:23:19 UTC --- (In reply to comment #7) > Could you supply a complete test case? I'd like to check this out, but# > I don't use OpenMP myself. Well, something along the following lines. Except for some declaration lines [and "default(share)"->"default(shared)], the example is really the one of comment 5. You can tune the number of threads using the OMP_NUM_THREADS environment variable. However, as said before (comment 6): As the "tmp" variable is generated in the parallel block, it should be created on the thread-private stack and there should be no issue. implicit none integer :: i real :: A(5), B(5) B = [real :: 1, 2, 3, 4, 5 ] !$omp parallel do default(shared) do i = 1, 5 A(i) = 5*cos(B(i))+8*cos(B(i)) end do print *, A end * * * Actually, I wonder in that case, how WORKSHARE will be handled, e.g. implicit none integer :: i real :: A(5), B(5) B(1) = 3.344 A = [real :: 1, 2, 3, 4, 5 ] !$omp parallel default(shared) !$omp workshare A(:) = A(:)*cos(B(1))+A(:)*cos(B(1)) !$omp end workshare nowait !$omp end parallel ! sync is implied here print *, A end Answer: With -O, one gets an ICE: omp.f90:7:0: internal compiler error: gfc_trans_omp_workshare(): Bad statement code
